What problem/issue/behavior are you having trouble with? What do you expect to see?
We would like to have a Red Hat supported version of the External Secret Operator [1].
The reason is that secret management is crucial for our Production environments as we are using a Gitops,
and we like the approach of the External Secret Operator as we believe is less invasive that other options such as Hashicorp Vault or CSecrets Store CSI Driver, but currently is just an Open Source project, and we would like Red Hat to support it.
We think is the only missing piece to have a fully supported and secure CI/CD Gitops workflow, in combination with OpenShift Gitops, and OpenShift Pipelines.
A second reason related to the first is because SSCSID needs a pod webhook to really have it work well. You can not easily use SSCSID secrets to reference them in ingress, or dockerconfig for pulling images, since a goal can be just to mount to a pod. Even if you want to enable k8s secret sync, you need to first mount the secret to a pod to sync it. This means it can not always (easily) be used as a drop-in replacement.
What is the business impact? Please also provide timeframe information.
The reason is that secret management is crucial for our Production environments as we are using a Gitops, and we like the approach of the External Secret Operator as we believe is less invasive that other options such as Hashicorp Vault or CSecrets Store CSI Driver, but currently is just an Open Source project, and we would like Red Hat to support it.
We think is the only missing piece to have a fully supported and secure CI/CD Gitops workflow, in combination with OpenShift Gitops, and OpenShift Pipelines.
- is duplicated by
-
ACM-1506 ACM Downstream and Support External Secrets Operator
- Closed
- relates to
-
OCPSTRAT-1539 External Secrets Operator (ESO) support in OpenShift Platform Plus (TechPreview)
- Refinement