Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
uhthomas opened this issue Nov 4, 2023 · 4 comments
Labels
bug Something isn't working

Comments

@uhthomas
Copy link

uhthomas commented Nov 4, 2023

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 uhthomas added the bug Something isn't working label Nov 4, 2023
@uhthomas
Copy link
Author

uhthomas commented Nov 4, 2023

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

#18

@uhthomas
Copy link
Author

uhthomas commented Nov 4, 2023

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

@ak-sundae
Copy link

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants