Annoyed of handling sealed secrets in your kubernetes cluster? This tool is for you!
- Reads a sealed secret resource as input
- Obtains the decrypted secrets from your cluster
- Lets you interactively edit the decrypted secrets in your favourite editor
- The secret values get decoded and displayed human-readable
- If json data is detected in the secret, you can edit it seperately
- Encrypts the secrets back and updates the sealed secret resource
- You have direct access to the kubernetes cluster through kubectl
- You use a git-first workflow
- You use bitnami's sealed secrets
- kubectl
- kubeseal > 0.24.1
- python3
./secretseal.py edit <sealed-secret-file> -c <path-to-sealed-secrets-certificate>
- Edit the secrets
- Save and exit
- Review the changes
- Git push
Our git repository is structured as follows:
.
└── k8s
├── cluster1
│ ├── namespace1
│ │ ├── deployment.yaml
│ │ └── application-secrets.yaml
│ ├── namespace2
│ │ ├── deploymentA.yaml
│ │ ├── deploymentB.yaml
│ │ ├── mail-secrets.yaml
│ │ └── db-secrets.yaml
│ └── crt.tls <-- this is the sealed secret certificate (gitignored)
└── cluster2
└── crt.tls
My workflow so far was:
- I get the certificate from the cluster by running
kubeseal --fetch-cert --controller-namespace <namespace> > crt.tls
- I obtain the decrypted secret(s) from the cluster
- I edit the secret
- If some keys are json, I copy the json data to a temporary file to have highlighting and linting
- I copy all values back to one file
- I create a secret with
kubectl create secret generic mail-secrets --from-file=secret.json --dry-run=client -o yaml > application-secrets-plain.yaml
- I encrypt the secret with
kubeseal --cert crt.tls < application-secrets-plain.yaml > application-secrets.yaml
Now I can do all of this with two commands when in the k8s/cluster1/namespace1
directory:
kubeseal --fetch-cert --controller-namespace <namespace> > ../crt.tls
./secretseal.py edit application-secrets.yaml
- This script will overwrite the original sealed secret file
- Edited secrets won't be applied to the cluster automatically -> git-first workflow
- You cannot edit a secret iteratively, since the actual secrets are read from the cluster
- This will not be actively maintained