Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

External Secrets Operator for general cluster use #450

Open
wadebee opened this issue Mar 26, 2024 · 3 comments
Open

External Secrets Operator for general cluster use #450

wadebee opened this issue Mar 26, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@wadebee
Copy link
Contributor

wadebee commented Mar 26, 2024

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:

  • Is cluster-wide usage of this operator VP-sanctioned or is this operator intended/configured only to support the VP infrastructure itself?
  • Is there a reason VP has prefixed this folder naming with golang? Without closer inspection - many folks might assume this is a different workload than the one most are familiar with.

Thanks,
Wade

@mbaldessari
Copy link
Contributor

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.

@wadebee
Copy link
Contributor Author

wadebee commented Mar 27, 2024

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.

@mbaldessari
Copy link
Contributor

Oh those are excellent points, thanks for bringing them up!

@claudiol claudiol added the enhancement New feature or request label Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants