Add CRDs as alternative to annotations.

[stefanhenseler]

Is your feature request related to a problem? Please describe.
We use ArgoCD for our Deployments. The problem with the Annotations approach is, that we have to ignore diffs for the generated secrets which is not ideal. Also, with every sync, the password is being regenerated, because ArgoCD applies the Annotation stanza, which causes the secret to be regenerated, because the annotation contains the status.

Describe the solution you'd like
I think it would be ideal if secret generator would offer CRDs similar to this project: https://github.com/vmware-tanzu/carvel-secretgen-controller.

Describe alternatives you've considered
I didn't consider any alternatives yet. I think for this particular issue, using CRD's is the only way. We need to store the output of the reconciler in a status field rather than the annotation.

Additional context
Add any other context or screenshots about the feature request here.

[martin-helmich]

This would make things certainly easier to handle, especially when Secret annotations are frequently updated (however, I have to ask: I know of quite a few controllers that use annotations for persisting state -- does ArgoCD actually reset all annotations on each deployment?).

As to possible alternatives: This feature might be a bit of a competition to #28 (although I suspect that the approach mentioned there would not be any help in your case, as it'd probably still rely on annotations to persist state).

As always: PRs (that maintain backwards compatibility) are welcome. 🙂

[YannikBramkamp]

I took the liberty of attempting to implement this. So far I have a working poc that watches the configured namespace for CRs and creates matching secrets, which are owned by the respective CRs for automated deletion.

The implementation uses one CR for each type of generated secret: string for generic random string secrets, basicauth to generate basic-auth secrets and sshkeypair for ssh key pairs. All support the same features as the annotation version, e.g. string can be supplied with a list of fields to generate, as well as arbitrary data fields such as usernames.

Implementing the storage of reconciler-output in status variables and bringing the code to a level that is actually presentable might take me a while, though.

[mittwald-machine]

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

[mittwald-machine]

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

[mittwald-machine]

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

[mittwald-machine]

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

[mittwald-machine]

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.

[mittwald-machine]

There has not been any activity to this issue in the last 30 days. It will automatically be closed after 7 more days. Remove the stale label to prevent this.