PushSecret spec.template is not propagated with a Kubernetes cluster->cluster SecretStore

[pre]

According to the documentation in https://external-secrets.io/v0.9.17/guides/pushsecrets/, PushSecret spec.template exists. However, nothing is copied with a Kubernetes cluster->cluster SecretStore.

External Secrets Operator v0.9.17

To Reproduce
Given the following PushSecret, only the attribute defined in spec.data is copied to the remote Secret.

Nothing from spec.template.metadata.labels or spec.template.data is copied to the remote Secret.

I also tried what happens when spec.data is not present at all: then the remote Secret is not created at all even though PushSecret .status shows message: PushSecret synced successfully.

apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
  name: ps-example
spec:
  refreshInterval: 30m
  secretStoreRefs:
  - name: example-store
    kind: SecretStore
  selector:
    secret:
      name: example-secret 
  template:
    metadata:
      labels:
        app.kubernetes.io/part-of: argocd
    data:
      example-1: "{{ .url | toString }}"
  data:
  - match:
      secretKey: url
      remoteRef:
        remoteKey: example-remote-key
        property: url

Expected behavior
The .spec.template should be reflected to the remote Secret.

Related

• PushSecret/Kubernetes: allow cloning of Secrets across clusters #2836
• Support pushing secrets' metadata to providers #3353

[ron1]

What provider are you using? Using the kubernetes provider, spec.template.data behaves as expected for me. As mentioned in #3353, spec.template.metadata is currently broken.

[pre]

I'm using the Kubernetes provider with External Secrets Operator v0.9.17.

Given the following SecretStore

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: example-secretstore
spec:
  provider:
    kubernetes:
      auth:
        token:
          bearerToken:
            name: example-resource-name
            key: token
      remoteNamespace: argocd
      server:
        url: ".. api url .."
        caProvider:
          type: Secret
          name: example-resource-name
          key: ca.crt

The following PushSecret only copies the url attribute. The example-1 attribute is not present in the remote Secret (only url is).

apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
  name: ps-example
spec:
  refreshInterval: 30m
  secretStoreRefs:
  - name: example-secretstore
    kind: SecretStore
  selector:
    secret:
      name: example-source-secret
  template:
    metadata:
      labels:
        app.kubernetes.io/part-of: argocd
    data:
      example-1: "test"
  data:
  - match:
      secretKey: url
      remoteRef:
        remoteKey: example-remote-secret
        property: url

[ron1]

Does the spec.template.data get pushed if you remove the property field as is done in the example on page https://external-secrets.io/latest/api/pushsecret/ ? I don't think we are intended to use templating and specify properties in the same PushSecret.

[gusfcarvalho]

@ron1 you can even do it - but then you need to address the generated template key (example1) in this case:

apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
  name: ps-example
spec:
  refreshInterval: 30m
  secretStoreRefs:
  - name: example-secretstore
    kind: SecretStore
  selector:
    secret:
      name: example-source-secret
  template:
    metadata:
      labels:
        app.kubernetes.io/part-of: argocd
    data:
      example-1: "test"
  data:
  - match:
      secretKey: example-1 ## Valid
      remoteRef:
        remoteKey: example-remote-secret
        property: url

[belaytzev]

I have the same issue, and neither .spec.template.metadata nor .spec.data[0].metadata are working right now

[moolen]

Thanks for bumping this issue, i'll take a look at it.

[moolen]

👋 Hello folks, i have a proposal in #3600, please take a look at the design, it should address all points raised in this issue. I'll leave the PR open for a couple of weeks to get feedback on the design.

[ErikLundJensen]

Do we have room for a simpler implementation than PR #3600 ?