Uploaded image for project: 'External Secrets Operator for Red Hat OpenShift'
  1. External Secrets Operator for Red Hat OpenShift
  2. ESO-2

External Secrets Operator (ESO) support in OpenShift (TechPreview)

XMLWordPrintable

    • ocp-eso-tp
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • Done
    • OCPSTRAT-1539 - External Secrets Operator (ESO) support in OpenShift (TechPreview)
    • OCPSTRAT-1539External Secrets Operator (ESO) support in OpenShift (TechPreview)
    • 0% To Do, 0% In Progress, 100% Done

      Epic Overview (aka. Goal Summary)

      Secrets management is a key part of the Red Hat Security posture, enabling customers to integrate with external secret management systems like AWS Secrets Manager, HashiCorp Vault, Google Secrets Manager, Azure Key Vault, IBM Cloud Secrets Manager, CyberArk Conjur and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret.

      The goal is to provide customers an vendor agnostic tool by which they can make secrets available to workloads running on OpenShift. ESO should be able to  synchronize secrets from external APIs into Kubernetes and manage the lifecycle of these secrets on the cluster. 

       ** 

      Goals (aka. expected user outcomes)
      Day 2 Operator that can be deployed on OpenShift clusters by administrators to facilitate communication with an external secrets manager and consumption of secrets by workloads on the cluster via 3rd party Providers. 

       

      Requirements (aka. acceptance criteria)

      Requirements
      CI - Must be running successfully with automated testing (this includes some minimal functional testing with 3rd party providers)
      CI - must include testing for HashiCorp Vault
      The operator must be released with OLM bundles and can be managed by OLM
      Quay generator support feature must be included
      Productization and release of operator using conflux, issue support and maintenance of operator and operand
      ESO must include support for Workload Identity Federation (WIF)

       

      Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

      Deployment considerations List applicable specific needs (N/A = not applicable)
      Self-managed, managed, or both Self-managed
      Classic (standalone cluster) Y
      Hosted control planes Y
      Multi node, Compact (three node), or Single node (SNO), or all  
      Connected / Restricted Network Y
      Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x)  
      Operator compatibility  
      Backport needed (list applicable versions)  
      UI need (e.g. OpenShift Console, dynamic plugin, OCM)  
      Other (please specify)  

              bhb@redhat.com Bharath B
              bhb@redhat.com Bharath B
              Siddhi Bhor, Swarup Ghosh
              Keenon Lee Keenon Lee
              Shubha Narayanan Shubha Narayanan
              Nick Png Nick Png
              Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: