Allow adding labels/annotations to every secret the controller creates

We want every Secret the controller creates to carry a label we choose.

Our case is Velero. We want backups to keep the SealedSecret, which is encrypted and restorable, and skip the Secret generated from it, which is just plaintext sitting in our backup bucket. For that, every generated Secret needs velero.io/exclude-from-backup: "true".

Today the only place to set that is spec.template.metadata on each SealedSecret. It works, but it has to be remembered by everyone who creates one: our operator, CI, and people running kubeseal by hand. With --raw you assemble the manifest yourself, so it's even easier to miss. One forgotten label and the plaintext is back in the backup, and nothing tells you.

What we'd like is controller flags:

--additional-secret-labels=key1=value1,key2=value2
--additional-secret-annotations=key1=value1

merged onto the Secret at unseal time. Two things matter to us:

• if a SealedSecret sets the same key in its own template, the template should win
• applied on update and recreate, not only on create, so Secrets that already exist pick it up after a controller restart or resync. Otherwise adopting this needs a separate migration for everything already in our clusters.

Why we'd rather not solve it outside the controller: --privatekey-labels only covers the sealing keys, and the Helm chart's commonLabels only covers what the chart renders. That leaves an admission policy (Kyverno, or MutatingAdmissionPolicy) matching ownerReferences[].kind == SealedSecret. We have that working, but we don't love it. It puts a mutating webhook in front of every Secret in the cluster. It only fires at admission, so anything already created stays unlabelled. It has to fail open or it blocks Secret writes cluster-wide, which means a label can be missed silently and nothing retriggers it. And it misses Secrets that use sealedsecrets.bitnami.com/skip-set-owner-references, since there's no owner reference to match on. That's a lot of moving parts for metadata the controller is already writing.

You already do this for the sealing keys with --privatekey-labels and --privatekey-annotations (#949), so this is the same idea applied to the Secrets the controller unseals.

#1625 looks related but it's about labels on the SealedSecret object itself, not on the generated Secret.

Happy to send a PR if you're open to it. Just say what you want the flags called, and whether template-wins is the precedence you'd expect.

Sponsored by Obmondo.