Open wadebee opened 8 months ago
Hi Wade,
the name is prefixed with golang- purely out of historical reasons: there was an older chart with the same name that was written in javascript and to differentiate we added golang. Not the best choice I suppose, but that is why it has that prefix now. I suspect that renaming it is just not worth the hassle and the eventual compatibility headache.
We'd like to switch to the ESO operator as well (as opposed to the chart), as in general we sort of favor operators as they are in a position to handle more cases (especially upgrades) than their non-operator counterparts. So it's planned for us to switch to the operator ESO, we just have not gotten around it yet.
Ok thanks for the clarification about Helm Chart vs Operator. I hadn't picked up on that nuance but yes I see now there is a nice administrative front-end for the ESO operator that could simplify management.
We will leave our existing operator-based implementation in place but look forward to this becoming part of the VP common offering.
One ask when it comes time to implement this (if possible).
Could you parameterize the Operator in such a way that the end-user can override the repo where images are pulled? Currently I have to modify our cluster as follows because we cannot reach out directly to ghcr.io/external-secrets/external-secrets-helm-operator
that is hard-coded into this operator.
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
name: image-policy-ghcr
spec:
repositoryDigestMirrors:
- mirrors:
- nexus-proxy.mycompany.com/external-secrets/external-secrets-helm-operator
source: ghcr.io/external-secrets/external-secrets-helm-operator
Further - because this operator uses an image digest value (versus an image label) and ICSP's don't support pulls with digest SHA values we also need to add this additional modification to force an edit to the mirror-by-digest-only = false
setting
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: worker
name: 99-worker-mirror-by-digest-registries-ghcr
spec:
config:
ignition:
version: 3.1.0
storage:
files:
- contents:
source: data:text/plain;charset=utf-8;base64,W1tyZWdpc3RyeV1dCnByZWZpeCA9ICIiCmxvY2F0aW9uID0gImdoY3IuaW8vZXh0ZXJuYWwtc2VjcmV0cy9leHRlcm5hbC1zZWNyZXRzLWhlbG0tb3BlcmF0b3IiCm1pcnJvci1ieS1kaWdlc3Qtb25seSA9IGZhbHNlCgpbW3JlZ2lzdHJ5Lm1pcnJvcl1dCmxvY2F0aW9uID0gIm5leHVzLm15Y29tcGFueS5jb20vZXh0ZXJuYWwtc2VjcmV0cy9leHRlcm5hbC1zZWNyZXRzLWhlbG0tb3BlcmF0b3Ii
overwrite: true
filesystem: root
mode: 420
path: /etc/containers/registries.conf.d/99-worker-mirror-by-digest-registries-ghcr.conf
which decodes to:
[[registry]]
prefix = ""
location = "ghcr.io/external-secrets/external-secrets-helm-operator"
mirror-by-digest-only = false
[[registry.mirror]]
location = "nexus-proxy.mycompany.com/external-secrets/external-secrets-helm-operator"
Complicating this workaround even more is the upcoming deprecation of ICSPs after Openshift 4.12.
All of this would be greatly simplified if the operator was parameterized to take alternate repo(s) for image pulls.
Oh those are excellent points, thanks for bringing them up!
We have been adding the External Secrets Operator (Community Maintained) to our values file as a required subscription.
In reviewing the Validated Patterns common folder today I found a folder named golang-external-secrets that upon closer inspection contains the same operator we need (but in a localized format).
Because our company does not allow direct access to public repos like ghcr.io where that operator is hosted I would like to make cluster-wide use of your localized instance.
My questions:
Thanks, Wade