Setting `destination` -> `label` does not seem to set label on end secret

[kiich]

More of a question rather than a bug I'm sure because this feature is clearly documented so I am sure my config of the vaultstaticsecret is wrong.

I have the following yaml:

kind: VaultStaticSecret
metadata:
  name: my-secret
  namespace: my-namespace
spec:
  destination:
    create: true
    labels:
      app.kubernetes.io/component: secret-sync
      app.kubernetes.io/managed-by: by-some-tool
      app.kubernetes.io/name: my-secret
    name: my-secret
    overwrite: true
    transformation:
      excludeRaw: true
      excludes:
      - .*
      templates:
        .dockerconfigjson:
          text: |
[...]
    type: kubernetes.io/dockerconfigjson
  hmacSecretData: true
  mount: my-kv/kv-v2
  namespace: my-namespace
  path: hashicorp-vso/my-secret

and my expectation was i would see kube secret created with the labels:

      app.kubernetes.io/component: secret-sync
      app.kubernetes.io/managed-by: by-some-tool
      app.kubernetes.io/name: my-secret

as per vso doc at https://github.com/hashicorp/vault-secrets-operator/blob/main/docs/api/api-reference.md#destination

but the end secret instead has:

            "app.kubernetes.io/component": "secret-sync",
            "app.kubernetes.io/managed-by": "hashicorp-vso",
            "app.kubernetes.io/name": "vault-secrets-operator",

i.e. the managed-by and name is somehow not being set?

I thought it might be due to the fact i am setting:

    create: true
    overwrite: true

but the doc does seem to suggest this is fine.
FYI, i've tried it with both non-existing secret (so creating it from scratch) as well as existing secret.

Is my config the problem here and also where are the values above coming from? (clearly from hashicorp-vso but i don't know where since i don't have that in any config)

version: hashicorp/vault-secrets-operator:0.5.2

[budgester]

Looks like the labels are set here.

vault-secrets-operator/helpers/secrets.go

Lines 48 to 60 in 0c640ae

	var labelOwnerRefUID = fmt.Sprintf("%s/vso-ownerRefUID", secretsv1beta1.GroupVersion.Group)
	// OwnerLabels will be applied to any k8s secret we create. They are used in Secret ownership checks.
	// There are similar labels in the vault package. It's important that component secret's value never
	// intersects with that of other components of the system, since this could lead to data loss.
	//
	// Make OwnerLabels public so that they can be accessed from tests.
	var OwnerLabels = map[string]string{
	ManagedByLabel: "hashicorp-vso",
	AppNameLabel: "vault-secrets-operator",
	ComponentLabel: "secret-sync",
	}

[budgester]

I am having a similar issue, we are deploying devspaces on openshift and labels are used to identify if a component is part-of the application, as VSO is grabbing the component label it stops us using VSO to deploy and use a secret for devspaces, the StaticSecret we are using is

---
apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: devspaces-bitbucket-oauth
  namespace: openshift-devspaces
spec:
  vaultAuthRef: vault-auth-jwt
  mount: kv
  type: kv-v2
  path: ocp/devspaces-bitbucket-oauth
  refreshAfter: 1h
  destination:
    create: true
    overwrite: true
    name: devspaces-bitbucket-oauth
    labels:
      app.kubernetes.io/part-of: che.eclipse.org
      app.kubernetes.io/component: **oauth-scm-configuration**
    annotations:
      che.eclipse.org/oauth-scm-server: bitbucket
      che.eclipse.org/scm-server-endpoint: 'https://bitbucket.myorg.co.uk'

but what we get when it is deployed to our cluster is with the VSO labels and our required component label is not applied.

$ oc describe secret devspaces-bitbucket-oauth
Name:         devspaces-bitbucket-oauth
Namespace:    openshift-devspaces
Labels:       **app.kubernetes.io/component=secret-sync**
              app.kubernetes.io/managed-by=hashicorp-vso
              app.kubernetes.io/name=vault-secrets-operator
              app.kubernetes.io/part-of=che.eclipse.org
              secrets.hashicorp.com/vso-ownerRefUID=c51c1071-fcc2-40d3-8ec7-def1e7afe0a9
Annotations:  che.eclipse.org/oauth-scm-server: bitbucket
              che.eclipse.org/scm-server-endpoint: https://bitbucket.myorg.co.uk

Type:  Opaque

Data
====
_raw:    259 bytes
id:      32 bytes
secret:  64 bytes

The way VSO deploys the labels means that a secret can never be a component of another application.

So maybe we could have a setting like overridelabels: true which would allow us to use our own labels ?

https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

Devspaces documentation - https://docs.redhat.com/en/documentation/red_hat_openshift_dev_spaces/3.25/html/administration_guide/configuring-devspaces#configuring-oauth-2-for-a-bitbucket-server-applying-an-oauth-2-application-link-secret-for-the-bitbucket-server