Retrieve the secret controller’s public key and use it to seal (encrypt) secrets. The Sealed Secrets are committed to the Git repository and later installed into the Kubernetes cluster by the GitOps process. Only the secret controller, which generated a public/private key pair, can decrypt the Sealed Secrets inside the Kubernetes cluster.
If your cluster has public nodes (which is true for the local dev cluster setup in these instructions), you can obtain and save the public key using:
If you are using an existing cluster that is private (
kubeseal cannot reach the secret controller because of network policies), you need to copy the secret controller’s key from the secret controller’s log file into the key file stored locally. If you have administrative permission to the cluster with
kubectl, you may be able to get the logs by executing the following command:
kubectl logs -n kube-system deployment/sealed-secrets-controller
When you obtain the public key, store it in a file located at
secrets/keys/dev.crt. This file need not be checked into the repository, however it is not secret information. The remaining setup scripts look in the
secrets/keys/dev.crt location for the public key in order to encrypt the secrets.
See the Bitnami docs for long term management of secrets and more details on private clusters .
You can validate your
secrets/key/dev.crt file contents with:
Verify with a result that looks similar to:
The process for sealing secrets will follow this pattern (example commands are given after this explanation):
- Create a local text file containing the secrets that are to be sealed. This file contains the raw secret data and should be protected like any secret.
- Create a local Kubernetes Secret manifest file using the
kubectl create secret file command and put the file into a staging area. This file contains raw secret data (in base64 encoding) and should be protected like any secret.
kubeseal command is run with the secret controller’s public key and the Kubernetes Secret file you created in the previous step. This encrypts and creates a Sealed Secret Kubernetes manifest file. This file contains the encrypted secret and can be safely committed to a git repository (even a public one) as only the secret controller can decrypt the secret with its internal private key.
- Commit and push the Sealed Secret files to the repository.
- FluxCD will syncronize the Sealed Secrets to the Kubernetes Cluster.
- The Sealed Secret controller inside the Kubernetes cluster observes the new Sealed Secrets and unseals them installing them as Opaque Secrets inside the cluster.
The following steps guide you through this process.
In the below commands, the namespace, secret name, and generic secret file name are specific and linked to subsequent commands. Do not change these values without understanding the
There are two specific secrets required to utilize this project.
ccloud CLI login credentials are used to manage the Confluent Cloud resources. Create a file that contains the following:
Ensure you do not commit this file to any repository and protect it like you would any secret. Execute the following
kubectl create secret command, passing the path to the
ccloud credentials file you just created into the
kubectl create secret generic cc.ccloud-secrets --namespace=default --from-env-file=<path-to-your-file> --dry-run=client -o yaml > secrets/local-toseal/dev/default-cc.ccloud-secrets.yaml
The project contains microservices, which utilize a MySQL database to demonstrate Connect and Change Data Capture. Credentials for the database need to be created as a Secret inside the Kubernetes cluster. An example of the layout of this file can be found in the sample
secrets/example-connect-operator-secrets.props. There isn’t a need to create a personal copy of the database credentials file, as that service is ran entirely inside the Kubernetes cluster and is not publicly accessible. Therefore, you can just use the provided example file.
kubectl create secret generic connect-operator-secrets --namespace=default --from-env-file=./secrets/example-connect-operator-secrets.props --dry-run=client -o yaml > secrets/local-toseal/dev/default-connect-operator-secrets.yaml
The above commands have created generic Kubernetes Secret manifests from your plain text secrets files and put them into a staging area (
secrets/local-toseal/dev). Now you will seal the secrets with the following
make target which, in turn, uses the
scripts/seal-secrets.sh script. This command will place the sealed secrets in
secrets/sealed/dev, and these files are safe to commit to the Git repository. This command will also delete the unsealed secret files from the staging area (
You should see the following:
➜ ./scripts/seal-secrets.sh dev
INFO - Successfully sealed secrets/local-toseal/dev/default-cc.ccloud-secrets.yaml
INFO - Successfully sealed secrets/local-toseal/dev/default-connect-operator-secrets.yaml
Now you can commit the sealed secret to the repository so that Flux can sync it to the K8s cluster:
git add secrets/sealed/dev/.
git commit -m 'New secrets!'
git push origin main # (or to the appropriate branch if you are doing GitOps by PR already!)