Implement Kubernetes PushSecret metadata

[moolen]

Towards #3443. This PR enhances the Kubernetes provider to support both .spec.template.metadata and .spec.data[0].metadata. It allows users to define both labels and annotations on the target secret.

⚠️ Both labels and annotations will be pushed by default into the target secret. It is not a opt-in feature and may cause undesired side-effects. Users can opt out by setting targetMergePolicy=Ignore.

👆 this is up for discussion. My point is that it should push the metadata by default, as expected by users described in #3443.

TODOs:

• update documentation
  • write section about metadata support
  • display structure of PushSecretMetadata
  • precedence of metadata
• add spec.targetMergePolicy to control the behaviour when writing the metadata to the target secret, e.g. Merge or Override
• add spec.metadataMergePolicy to control if the source secret metadata (that includes the template metadata) and the .data[].metadata is merged or replaced.

---

PushSecret Metadata

The Kubernetes provider is able to manage both metadata.labels and metadata.annotations of the secret on the target cluster.

Users have different preferences on what metadata should be pushed. ESO by default pushes both labels and annotations to the target secret and merges them with the existing metadata.

You can specify the metadata in the spec.template.metadata section if you want to decouple it from the existing secret.

apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
  name: example
spec:
  # ...
  template:
    metadata:
      labels:
        app.kubernetes.io/part-of: argocd
    data:
      mysql_connection_string: "mysql:https://{{ .hostname }}:3306/{{ .database }}"
  data:
  - match:
      secretKey: mysql_connection_string
      remoteRef:
        remoteKey: backend_secrets
        property: mysql_connection_string

Further, you can leverage the .data[].metadata section to fine-tine the behaviour of the metadata merge strategy. The metadata section is a versioned custom-resource alike structure, the behaviour is detailed below.

apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
  name: example
spec:
  # ...
  data:
  - match:
      secretKey: example-1
      remoteRef:
        remoteKey: example-remote-secret
        property: url
        
    metadata:
      apiVersion: kubernetes.external-secrets.io/v1alpha1
      kind: PushSecretMetadata
      spec:
        sourceMergePolicy: Merge # or Replace
        targetMergePolicy: Merge # or Replace / Ignore
        labels:
          color: red
        annotations:
          yes: please

Field	Type	Description
sourceMergePolicy	string: Merge, Replace	The sourceMergePolicy defines how the metadata of the source secret is merged. Merge will merge the metadata of the source secret with the metadata defined in .data[].metadata. With Replace, the metadata in .data[].metadata replaces the source metadata.
targetMergePolicy	string: Merge, Replace, Ignore	The targetMergePolicy defines how ESO merges the metadata produced by the sourceMergePolicy with the target secret. With Merge, the source metadata is merged with the existing metadata from the target secret. Replace will replace the target metadata with the metadata defined in the source. Ignore leaves the target metadata as is.
labels	map[string]string	The labels.
annotations	map[string]string	The annotations.

[ron1]

Do you plan to eventually upgrade #2600 to be consistent with this enhanced approach to managing pushsecret metadata?

[moolen]

Oh, i see. It's actually the same thing i'm using here, it's just documented wrong 😞 its .data[].metadata not under the remoteRef.metadata. let me update that asap

[ron1]

This PR introduces a more sophisticated schema that moves the annotations and labels fields below the new spec field and defines new merge policy fields. Will the other provider be eventually upgraded to support this new schema?

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[moolen]

This PR introduces a more sophisticated schema that moves the annotations and labels fields below the new spec field and defines new merge policy fields. Will the other provider be eventually upgraded to support this new schema?

This is up to discussion if we want such a "convoluted" structure for metadata parameters. We could also keep it simple and unversioned. Though that will bite us in the future.
#3581 will follow that approach as well.

[ron1]

Hi @moolen, is there a plan/timeframe for approving the linked PushSecret metadata proposal and subsequently moving this PR forward?

Thanks!

[ErikLundJensen]

This seem a bit overcomplication of things, however, we need the feature that adds labels and annotations to the pushed secrets.
The complication is inherit from the match-syntax, which is needed eventhough data is given in the template.

Getting rid of the match section when using template may ease the pain implementing this feature.