Repository navigation
Replies: 1 comment
|
Right now, my hack for this is to use a big ugly command like this: $ yq --arg serial $(\
kubectl seal --controller-name{,space}=sealed-secrets --fetch-cert \
| openssl x509 -noout -text \
| rg --after-context=1 'Serial Number:' \
| tail --lines 1 \
| tr --delete :) \
--in-place \
--yaml-roundtrip \
'.metadata.labels["gitops.example.domain/sealing-cert-serial"] = $serial' \
path/to/my/sealedsecret.yamlBut since kubeseal knows which certificate it's sealing with, it could surely write this label for me. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
As a long time user of sealed secrets, I've read through the docs many times and haven't found any mention of anything similar to this idea. It's something we've started doing manually, but I think it could be valuable for the
kubesealcli to automate.To help identify the age of our secrets, I've started labeling our sealed secrets with something along the lines of
gitops.example.domain/sealing-cert-serial: 04-f6-00-7e-76-e6-32-7c-ce-e2-f1-da-3e-54-bc-78. This helps us track which certificates need to remain active through a simple code search, and enabling us to check clusters quickly if a secret is ever compromised with something likekubectl get sealedsecret --selector=gitops.example.domain/sealing-cert-serial=.... I think it'd be nice if the resulting sealed secret could have these labels applied automatically. That could also enable a CI workflow that checks for known or outdated certificate serial numbers!All reactions