Mastering Kubernetes Secret Management with Sealed Secrets: A Step-by-Step Guide

Introduction to the Need for Sealed Secrets in Kubernetes

Managing sensitive information like API keys, passwords, and tokens is crucial in any Kubernetes deployment. While Kubernetes has a native mechanism for handling secrets, these are stored in plaintext, making them vulnerable to unauthorized access if not properly secured. To solve this, Sealed Secrets provides a solution that enables encrypting secrets while allowing secure management across environments, especially in GitOps workflows.

Understanding the Components of Sealed Secrets

Sealed Secrets consists of two key components:

Sealed Secrets Operator: A Kubernetes controller responsible for decrypting secrets in the cluster.
Kubeseal CLI: A command-line tool that encrypts Kubernetes secrets into Sealed Secrets outside the cluster.

These components work together to ensure secrets are securely stored and transmitted. The Sealed Secrets Operator only allows decryption within the cluster.

How Sealed Secrets Enhance Security in GitOps Deployments

In GitOps, application configurations are stored in version-controlled repositories like Git. Storing sensitive information directly in Git can lead to severe security breaches if exposed. Sealed Secrets enhance security by ensuring that secrets are stored in an encrypted format in Git. Only the target Kubernetes cluster, using its unique private key, can decrypt and utilize these secrets, safeguarding them from unauthorized access during deployments.

Installing and Configuring the Sealed Secrets Operator

To begin using Sealed Secrets, the first step is installing the Sealed Secrets Operator in your Kubernetes cluster. Here are the steps to do so:

Install the Sealed Secrets Operator: Run the following command to install the operator via Helm:
helm install sealed-secrets-controller \

–namespace kube-system \

bitnami-labs/sealed-secrets

Verify the Installation: Once installed, verify the Sealed Secrets Operator is running by executing:
kubectl get pods -n kube-system -l app.kubernetes.io/name=sealed-secrets

Utilizing Kubeseal CLI for Encrypting Kubernetes Secrets

The Kubeseal CLI is essential for encrypting your Kubernetes secrets before committing them to Git. Here’s how you can use it:

Install Kubeseal CLI: You can install Kubeseal for your platform (Linux, MacOS, or Windows) from the Kubeseal GitHub releases page.
Create and Encrypt a Secret: First, create a standard Kubernetes secret file:
apiVersion: v1

kind: Secret

metadata:

name: my-secret

type: Opaque

data:

username: dXNlcm5hbWU= # Base64 encoded

password: cGFzc3dvcmQ= # Base64 encoded

Use Kubeseal to encrypt this file:
kubeseal –format yaml < my-secret.yaml > sealed-secret.yaml

The generated sealed-secret.yaml can be safely stored in Git.

Steps to Encrypt and Decrypt Secrets with Sealed Secrets

Sealed Secrets are designed to simplify the process of securely managing secrets. Here’s how you can handle encryption and decryption:

Encrypting Secrets: Use the Kubeseal CLI to encrypt secrets. As shown earlier, you take a Kubernetes secret and convert it into a Sealed Secret, which can only be decrypted by the Sealed Secrets Operator running in the Kubernetes cluster.
Decrypting Secrets: The Sealed Secrets Operator automatically decrypts Sealed Secrets when they are applied to the Kubernetes cluster, converting them back into regular secrets that your applications can access.

Best Practices for Securing the Sealing Key

The Sealed Secrets Operator uses a sealing key to decrypt secrets. Securing this key is critical to ensuring that your secrets remain safe. Some best practices include:

Back up the Sealing Key: Regularly back up the key to prevent data loss if the cluster is destroyed.
Rotate Keys Periodically: Ensure that you rotate your keys periodically to reduce the risk of long-term key exposure.
Restrict Access: Limit access to the sealing key by enforcing strict access control policies.

Exploring Scopes of Sealed Secrets for Controlled Decryption

Sealed Secrets allow you to control the scope of decryption based on namespace, controller, and other attributes. This ensures that even if Sealed Secrets are shared across multiple clusters, only the intended clusters or namespaces can decrypt them.

For example, you can limit a Sealed Secret to be decrypted only by a specific namespace using the scope attribute in your Sealed Secrets YAML:

apiVersion: bitnami.com/v1alpha1

kind: SealedSecret

metadata:

name: my-secret

namespace: my-namespace

spec:

encryptedData:

password: AgBwpc…

scope: namespace-wide

Conclusion

Sealed Secrets offer a robust, secure way to manage Kubernetes secrets, especially in GitOps environments where storing sensitive information in Git is a common practice. By encrypting secrets and ensuring they can only be decrypted within specific Kubernetes clusters, Sealed Secrets enhance security and streamline the deployment process.