Overview
Kubernetes provides the Secrets API to store sensitive data such as passwords, OAuth tokens, SSH keys, and certificates. While Kubernetes Secrets are stored in the cluster, they are not encrypted by default and can be accessed in plaintext. This creates a security risk when storing highly sensitive information, especially in multi-tenant or production environments.
One effective solution is Sealed Secrets, which allows you to encrypt Kubernetes Secrets before storing them in version control or as YAML files, ensuring they are safe even if exposed. Sealed Secrets ensures that sensitive data is encrypted and can only be decrypted by the Kubernetes cluster where it was intended.
In this blog, we will walk you through how to encrypt Kubernetes Secrets using Sealed Secrets and how to safely manage them in your cluster.
What are Sealed Secrets?
Sealed Secrets is a tool developed by Bitnami that provides an encryption mechanism for Kubernetes Secrets. It helps you to encrypt sensitive information in such a way that it can be safely stored in public or private version control systems.
Sealed Secrets works by:
Encrypting the contents of a Kubernetes Secret before storing it.
The encrypted secret (sealed secret) can be safely stored in version control or any other storage.
The secret can only be decrypted by the Kubernetes controller that is running within the cluster.
The encryption and decryption are handled using asymmetric cryptography, ensuring that only the intended Kubernetes cluster can decrypt the sealed secrets.
Why Use Sealed Secrets?
Before Sealed Secrets, the primary concern was managing sensitive data in a secure way, while Kubernetes Secrets did not offer encryption by default. Here’s why Sealed Secrets is beneficial:
Security: Sensitive data is encrypted and stored safely, preventing unauthorized access.
Version Control: You can safely store Sealed Secrets in your Git repository, making CI/CD workflows safer.
Single Source of Truth: You maintain a single declarative YAML file for your secrets, which can be versioned and managed.
Simplicity: Integration with existing Kubernetes workflows is easy, and no manual intervention is required to decrypt secrets.
How Sealed Secrets Works?
Here’s how it works:
The developer encrypts the secret on their local machine using a public key with the kubeseal CLI, converting the secret into a Sealed Secret (a Kubernetes Custom Resource Definition, or CRD).
The Sealed Secret CRD is deployed to the target Kubernetes cluster.
The Sealed Secrets controller in the cluster decrypts the Sealed Secret using a private key, creating a standard Kubernetes Secret.
The private key is securely stored and accessible only to the Sealed Secrets controller within the cluster, while the public key is available to developers. This ensures that only the cluster can decrypt the secrets, while developers can only encrypt them.
Prerequisites
Before you begin, make sure you have the following:
A Kubernetes cluster (local or cloud-based).
kubectl configured to interact with the cluster.
kubeseal, the Sealed Secrets CLI tool installed.
You can install kubeseal by running the following:
macOS:
brew install kubeseal
Linux:
curl -sSL https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.17.0/kubeseal-v0.17.0-linux-amd64.tar.gz | tar -xzv
sudo mv kubeseal /usr/local/bin/Installing & Using Sealed Secrets
Step 1: Install the Sealed Secrets Controller
The first step in using Sealed Secrets is to install the Sealed Secrets controller in your Kubernetes cluster. This controller is responsible for decrypting the Sealed Secrets and creating regular Kubernetes Secrets.
Run the following command to install Sealed Secrets:
kubectl apply -f https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.17.0/controller.yaml
This will deploy the Sealed Secrets controller into the kube-system namespace. You can verify its installation by checking for the Sealed Secrets controller pods:
kubectl get pods -n kube-system | grep sealed-secretsStep 2: Create a Kubernetes Secret
Now that the controller is installed, you can create a Kubernetes Secret as you normally would. Here's an example of a simple Secret that holds a database password:
apiVersion: v1
kind: Secret
metadata:
name: db-password
type: Opaque
data:
password: cGFzc3dvcmQ= base64 encoded password value
This Secret contains a password (password), which is base64-encoded. Save this YAML file as db-secret.yaml.
Step 3: Encrypt the Secret Using Sealed Secrets
To encrypt the Secret, use the kubeseal command. It will take the db-secret.yaml file, encrypt the secret data, and generate a Sealed Secret that can be safely stored.
Run the following command:
kubeseal < db-secret.yaml > db-sealedsecret.yaml
The kubeseal command reads the original Secret and outputs a Sealed Secret to the file db-sealedsecret.yaml.
The contents of the db-sealedsecret.yaml file look like this:
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: db-password
namespace: default
spec:
encryptedData:
password: AgB...
Notice that the data is now encrypted. This Sealed Secret can be safely stored in Git repositories or other places without compromising the sensitive information.
Step 4: Apply the Sealed Secret
To apply the Sealed Secret, use kubectl to deploy it into your cluster:
kubectl apply -f db-sealedsecret.yaml
The Sealed Secrets controller will detect the Sealed Secret and decrypt it automatically, creating the corresponding Kubernetes Secret in your cluster.
You can verify that the Secret was created successfully by running:
kubectl get secret db-password -o yaml
The output should display the decrypted secret:
apiVersion: v1
data:
password: cGFzc3dvcmQ=
kind: Secret
metadata:
name: db-password
namespace: default
type: Opaque
The password field now contains the decrypted value in base64 format.
Step 5: Using Sealed Secrets in Your Applications
Once the Secret is decrypted and available in your cluster, you can reference it in your Kubernetes deployments as usual. For example, to inject the db-password Secret into a pod, you can use it in a deployment like this:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: my-app-image
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-password
key: password
The application can now access the DB_PASSWORD environment variable, which will contain the decrypted password from the Secret.
Conclusion
Encrypting Kubernetes Secrets with Sealed Secrets provides a robust way to manage sensitive data in a secure manner. By encrypting your secrets before storing them in version control systems, you can ensure that they are protected from unauthorized access. The Sealed Secrets controller then decrypts them only within the intended Kubernetes cluster, ensuring a secure and streamlined workflow.
By using Sealed Secrets, you can maintain a high level of security while managing and deploying sensitive data in Kubernetes.
References
If you found this blog helpful, don't forget to like 👍, share 🔄, and subscribe 🔔 for more insightful content! Your feedback and engagement help us bring you more valuable resources. Feel free to drop your thoughts or questions in the comments below! 😊
Comments