search

1Password / onepassword-operator

The 1Password Connect Kubernetes Operator provides the ability to integrate Kubernetes Secrets with 1Password. The operator also handles autorestarting deployments when 1Password items are updated.
https://developer.1password.com/docs/connect/
MIT License
532 stars 59 forks source link

Labels should not be propagated from OnePasswordItem objects to Secret objects #178

Open uhthomas opened 10 months ago

uhthomas commented 10 months ago

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/

https://github.com/spotahome/redis-operator/issues/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

https://github.com/1Password/onepassword-operator/issues/144

https://github.com/1Password/onepassword-operator/issues/114

https://github.com/1Password/onepassword-operator/issues/102

https://github.com/1Password/onepassword-operator/issues/96

https://github.com/1Password/onepassword-operator/issues/84

https://github.com/1Password/onepassword-operator/issues/41

uhthomas commented 10 months ago

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

https://github.com/1Password/onepassword-operator/issues/18

uhthomas commented 10 months ago

In addition, the secret is never recreated after it's pruned because of https://github.com/1Password/onepassword-operator/issues/177.

ak-sundae commented 6 months ago

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 commented 6 months ago

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

https://github.com/kubernetes/kubernetes/issues/92896#issuecomment-655540826

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