Sealed Secrets
In this chapter, you will learn how to tie the secret management workflow and application delivery together using gitops.
How gitops unifies secret management with application deployment
With gitops, you store ConfigMaps
right next to your application yamls.
But you can also store Secrets
right next to your application manifests.
Encrypted.
No special treatment, no distinct secret workflows, no eventual consistency.
You store secrets right alongside your application configuration, deploy them the same way and at the same time. You version secrets together with your application, just encrypted.
It is made possible with the Sealed Secret's project.
The steps to use the Sealed Secrets controller
Bitnami's Sealed Secrets is based on asymmetric cryptography, just like your SSH keys or SSL.
Encrypt your
Secret
into aSealedSecret
, which is safe to store - even in a public repository. TheSealedSecret
can only be decrypted by the controller running in the target cluster and nobody else (not even the original author) is able to obtain the originalSecret
from theSealedSecret
.
Setup steps:
- You deploy the Sealed Secrets controller in your cluster
- In turn, it creates a key pair
- You download the public key that you will use for sealing all secrets
- Remember to make a backup of the private key, should you need to recover your cluster in case of an emergency.
Once you have the controller running and fetched the public key, you can use the Sealed Secret project's kubeseal
CLI to encrypt the secrets:
echo -n my-secret-value | kubeseal \
--raw --scope cluster-wide \
--controller-namespace=infrastructure \
--from-file=/dev/stdin
You can deploy SealedSecrets with Gimlet Stack. Follow the Gimlet Stack intro tutorial to install SealedSecrets.
tip
Sealed secrets cannot be decrypted without the private key, not even by their creator. All encrypted secrets in the gitops repository will be useless, if you need to recreate the cluster without the private key. So make sure to back it up during the installation process.