CUSTOMER PROBLEM

External Secrets Operator (ESO)  is a Kubernetes operator that integrates 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 of External Secrets Operator is to synchronize secrets from external APIs into Kubernetes. ESO is a collection of custom API resources - ExternalSecret, SecretStore and ClusterSecretStore that provide a user-friendly abstraction for the external API that stores and manages the lifecycle of the secrets for you.

ESO is chosen by customers when:

• They need ease of integration with platform and ease of use for developers
• They have high degree of trust in the control plane of the cluster - especially in how the etcd is configured with encryption or in how RBAC is managed on the cluster
• They have multi-cluster hub<>spoke use cases for secrets management and need cross-cluster secrets integrations, a recent example usecase came forth where cert-manager generates TLS secrets that get stored in Vault and then ESO is used to distribute trust in a multi-cluster environment.  
• They need Platform Secrets managed for non-application usage, for e.g for Ingress, automation, image pull secrets
• The secrets need to be modified on cluster with templating for specific applications
• And lastly and importantly, their use case needs secrets resource on the cluster such as used by OpenShift Operators.

Why Do we need ESO when we have SSCSI driver? 
SSCSI needs a pod to volume mount the secrets which is a cumbersome workflow. Upstream SSCSI project is also looking to split the Sync Secrets functionality in future to an independent controller such as ESO. See here. 

Other than that, there are usecase differences from SSCSI which are highlighted above that cannot be easily met with the SSCSI functionality. 

USERS

Application owners/Developers need ESO for ease of using Kubernetes secrets in their application by formating secrets with specific templates

Platform owners/admins/SREs need ESO to sync secrets from a centralized secrets management system to cluster services. 

ACCEPTANCE CRITERIA

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

QUESTIONS

This section should specify what questions we are trying to answer for the customer with this set of features.

ACTIONS

This section should specify what actions we are trying to enable the user to take with our product.

CONSIDERATIONS

This section may contain notes about any number of things that should be taken into consideration when building out this set of features, including (but not limited to) intended future direction for these features or for the corresponding feature family.

UX/UI

Generally mocks should be attached to individual stories. However, if mocks combine multiple individual stories in order to enable the best user interaction, then the mocks should be linked here and this section should denote which stories are encompassed by the mocks.

DELIVERY PRIORITY

This section should outline the desired order of delivery for stories comprising this epic. For example:

• https://stack-rox.atlassian.net/browse/ROX-2206
• https://stack-rox.atlassian.net/browse/ROX-2207
• https://stack-rox.atlassian.net/browse/ROX-2208