martin-helmich
commented
8 months ago Sorry for the late response. 🙏
An additional field in the CRD sounds definitely reasonable; it would probably make sense to mirror the API design of other Kubernetes resources, which often have a .spec.template property that is then copied into generated sub-objects (for example, when you want to control the labels of Pods that are created by a Deployment, you'd also set .spec.template.metadata.labels).
Thinking a bit further, we could even go so far as to also allow users to set spec.template.data to specify static parts of the secret that should not be managed by the secret generator (for example, for a username+password pair).
As mentioned in other issues, I cannot make any promises as to when we'd get around to adding this. In the meantime, PRs are always welcome. 🙂
Is your feature request related to a problem? Please describe. I want to use kubernetes-replicator with this secret generator but cannot since the StringSecret object does not allow me to set the correct annotations.
Describe the solution you'd like A new field to the CRD, perhaps called
metadata, allowing me to set labels and annotations.Describe alternatives you've considered Using annotations on an empty Secret, but Flux will attempt to manage the contents of it, removing the generated values. Using the custom resources allows for a clean GitOps flow.
Additional context This is similar to #73 but also includes labels in the list.
I saw in the code that labels are inherited but I don't necessarily want to copy every label or annotation onto the generated Secret.