Skip to content

Conversation

@mbaldessari
Copy link
Contributor

Currently we just push the hub ca in the golang-external-secrets
namespace. This is problematic once we move to the downstream ESO
because that uses different namespaces. In order to support both
ESO versions (upstream - golang-external-secret and downstream -
external-secrets) we tried different approaches.

Initially, we checked if a specific application existed

{{- $eso_ns := "golang-external-secrets" }}
{{- range .Values.clusterGroup.applications }}
  {{- if or (eq .chart "openshift-external-secrets") (and (hasKey . "repoURL") .repoURL (hasSuffix "openshift-external-secrets" .repoURL)) (and (hasKey . "repoURL") .repoURL (hasSuffix "openshift-external-secrets-chart" .repoURL))
    {{- $eso_ns = "external-secrets" }}
  {{- end }}
{{- end }}

The problem with the above is that is just too fragile.

The approach we actually use here is the lookup functionality in ACM:

If the "external-secrets-operator" namespace exists on the spoke, we can
safely assume that we are using the downstream ESO, in which case the
policy with the CA of the hub will be pushed to the external-secrets
namespace (where the real ESO pods run).

Tested this with both the old upstream golang-external-secrets and with
the downstream ESO.

Currently we just push the hub ca in the golang-external-secrets
namespace. This is problematic once we move to the downstream ESO
because that uses different namespaces. In order to support both
ESO versions (upstream - golang-external-secret and downstream -
external-secrets) we tried different approaches.

Initially, we checked if a specific application existed

    {{- $eso_ns := "golang-external-secrets" }}
    {{- range .Values.clusterGroup.applications }}
      {{- if or (eq .chart "openshift-external-secrets") (and (hasKey . "repoURL") .repoURL (hasSuffix "openshift-external-secrets" .repoURL)) (and (hasKey . "repoURL") .repoURL (hasSuffix "openshift-external-secrets-chart" .repoURL))
        {{- $eso_ns = "external-secrets" }}
      {{- end }}
    {{- end }}

The problem with the above is that is just too fragile.

The approach we actually use here is the lookup functionality in ACM:

If the "external-secrets-operator" namespace exists on the spoke, we can
safely assume that we are using the downstream ESO, in which case the
policy with the CA of the hub will be pushed to the external-secrets
namespace (where the real ESO pods run).

Tested this with both the old upstream golang-external-secrets and with
the downstream ESO.
@darkdoc
Copy link
Contributor

darkdoc commented Oct 30, 2025

/lgtm

@mbaldessari mbaldessari merged commit f2d9d08 into validatedpatterns:main Oct 30, 2025
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants