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.
Note
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:
-----BEGIN CERTIFICATE-----
MIIErTCCApWgAwIBAgIQH5QEHe0tYPRHi2fPNkCZITANBgkqhkiG9w0BAQsFADAA
MB4XDTIwMDkwMjE0MDcwOFoXDTMwMDgzMTE0MDcwOFowADCCAiIwDQYJKoZIhvcN
AQEBBQADggIPADCCAgoCggIBAKoUaCGavOp4Aqz9b3eTDibdytlq46jsBpBGfF7R
...
pzdWVMSumzZnWE/bu9+OQ4TX0d2p6ka/paOXuOObGOlJclex3lEc3Hw06iL9TnJJ
K4qei3kT6H/QlcjslyWaJtPO5liZLbjBBitXjONM3A8vLfKXA+3IVHG4QAr39jtv
2Q==
-----END CERTIFICATE-----
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.
- The
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.
Note
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 scripts/seal-secrets.sh
script.
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:
CCLOUD_EMAIL=your-ccloud-email
CCLOUD_PASSWORD=your-ccloud-password
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 --from-env-file
argument.
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 (secrets/local-toseal/dev
):
You should see the following:
Sealing-secrets-----------------------------------
➜ ./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!)