Allow labels to be added to the resulting secret

[Chumper]

I am currently working on setting up ArgoCD with the vault-secret-operator.

ArgoCD supports that credentials for git repository access can be declared beforehand:
https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#repository-credentials

Example:

apiVersion: v1
kind: Secret
metadata:
  name: first-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  url: https://github.com/argoproj/private-repo

ArgoCD relies on the labels to determine that a secret belongs to an ArgoCD installation.
So I would like to request that (in the easiest implementation) we can labels to the secret as well.

For my usecase it should be sufficient to add labels as an additional field in the spec:

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: example-secret
spec:
  keys:
    - url
  path: kvv1/example-vaultsecret
  type: Opaque
  labels:
    argocd.argoproj.io/secret-type: repository

Which would result in a secret like this:

apiVersion: v1
data:
  url: YmFyCg==
kind: Secret
metadata:
  labels:
    created-by: vault-secrets-operator
    argocd.argoproj.io/secret-type: repository
  name: example-secret
type: Opaque

I am not sure yet if this affects ArgoCD because the secrets are stored in data instead stringData but that should not be a concern here.

If needed I can try myself out by contributing this. I would expect it to be a rather simple change.

[ricoberger]

Hi @Chumper, we are already propagating the labels from the VaultSecret to the Kubernetes Secret:

apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
  name: example-secret
  labels:
    argocd.argoproj.io/secret-type: repository
spec:
  keys:
    - url
  path: kvv1/example-vaultsecret
  type: Opaque

The above VaultSecret would result in a secret like this:

apiVersion: v1
data:
  url: YmFyCg==
kind: Secret
metadata:
  labels:
    argocd.argoproj.io/secret-type: repository
  name: example-secret
type: Opaque

Does this already help for your use case?

[Chumper]

Hah! I only found in the documentation that the labels are available in templating.
That would solve all my problems!
Let me try that.

However in that case I would propose to add that to the documentation

[Chumper]

@ricoberger Indeed, that works and solves my use case.
Thank you for the hint!

In that case are you fine with me adding a section on the readme?

[ricoberger]

Nice and thanks for your additions to the readme 🙂