Labels should not be propagated from OnePasswordItem objects to Secret objects

[uhthomas]

Your environment

Operator Version: v1.8.0

Connect Server Version: N/A

Kubernetes Version: N/A

What happened?

As explained in a different project, propagating annotations and labels can be dangerous. In my case, this makes the operator incompatible with Kubernetes ApplySets.

https://kubernetes.io/blog/2023/05/09/introducing-kubectl-applyset-pruning/

spotahome/redis-operator#592

What did you expect to happen?

Labels should not be propagated from OnePasswordItem objects to Secret objects

Steps to reproduce

1. Create a OnePasswordItem object
2. Observe all annotations and labels are propagated

Notes & Logs

#144

#114

#102

#96

#84

#41

[uhthomas]

There is also no workaround for this, as the operator does not support StatefulSet objects.

#18

[uhthomas]

In addition, the secret is never recreated after it's pruned because of #177.

A 'should not be' is quite a strong and one-sided opinion. We, for example, rely on this particular functionality to deploy ArgoCD secrets (repository credentials, etc.) that must be labeled appropriately for ArgoCD to find them (argocd.argoproj.io/secret-type). There are multiple other objects that rely on labels/annotations, as mentioned in related issues.

As mentioned in #144 , there should be a way to support both options.

[uhthomas]

Inline with the behaviour of native Kubernetes resources, this should at least not be the default behaviour.

kubernetes/kubernetes#92896 (comment)

I do appreciate it may be desirable for some, and so should be optional.

[bradmac-ats]

Copying labels is necessary for storing ArgoCD Repository credentials in 1Password. the argocd.argoproj.io/secret-type: repository needs to be carried over or ArgoCD won't pick it up as a repository.

[uhthomas]

So maybe just some labels? Maybe there can be a special case for not propagating applyset labels specifically.

[volodymyrZotov]

Addressed in #229