Kubernetes secrets are about as secret as your browser history. They're stored in plaintext, viewable by anyone with cluster access, and let's not even get started on the nightmare of version control. Enter Sealed Secrets, the encryption wizard that's about to make your sensitive data actually... sensitive.

What's the big deal?

  • Encrypt your secrets before they hit version control
  • Automagically decrypt them in your cluster
  • Sleep better at night knowing your API keys aren't floating around the internet

By the end of this article, you'll be sealing secrets like a pro, impressing your colleagues, and maybe even landing that promotion. (Okay, I can't promise the promotion, but your secrets will definitely be safer.)

Sealed Secrets: The Superhero Origin Story

Kubernetes secrets, but with a cape and a mask. That's essentially what Sealed Secrets are. They're encrypted Kubernetes secrets that are managed by the Sealed Secrets controller. Think of it as your personal bodyguard for sensitive data.

Why Sealed Secrets are the Batman of Kubernetes:

  • They can safely hang out in your Git repo without exposing themselves
  • Only your Kubernetes cluster can see what's inside
  • They're like regular Kubernetes secrets, but with superpowers

Installing the Sealed Secrets Controller: Your New Best Friend

Before we start sealing secrets like there's no tomorrow, we need to install the Sealed Secrets controller.

Prerequisites:

  • A Kubernetes cluster (if you don't have one, what are you even doing here?)
  • kubectl configured and ready to roll

Let's get this party started with Helm:


# Add the Sealed Secrets repo
helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets

# Update your repos
helm repo update

# Install Sealed Secrets
helm install sealed-secrets sealed-secrets/sealed-secrets

Boom! Your cluster is now equipped with a secret-sealing superpower. Let's make sure it's up and running:


kubectl get pods -n kube-system | grep sealed-secrets

If you see a pod running, give yourself a pat on the back. You're officially in the secret-sealing business.

Creating and Encrypting a Sealed Secret: Espionage 101

Now that we've got our secret lair set up, it's time to start creating some classified documents. But first, we need the right tools.

Step 1: Install kubeseal

kubeseal is your encryption sidekick. Install it like this:


wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.18.1/kubeseal-linux-amd64 -O kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

Step 2: Create a Secret

Let's create a super-secret database password:


apiVersion: v1
kind: Secret
metadata:
  name: my-database-secret
type: Opaque
stringData:
  DB_PASSWORD: "supersecretpassword123"

Save this as secret.yaml. But remember, this file is about as secure as a papier-mâché safe.

Step 3: Seal that Secret!

Time to put that secret in a vault:


kubeseal --format yaml < secret.yaml > sealed-secret.yaml

Voila! You now have a sealed-secret.yaml that you can commit to Git without fear. It's like your secret got its own Iron Man suit.

Deploying Sealed Secrets: Mission Impossible

Now that we've got our secret all sealed up, let's deploy it to our cluster. It's like sending a classified document through enemy territory.


kubectl apply -f sealed-secret.yaml

The Sealed Secrets controller springs into action, decrypts your secret, and creates a regular Kubernetes Secret. Magic!

To verify, run:


kubectl get secrets

You should see your decrypted secret ready for your applications to use. Mission accomplished!

Managing Sealed Secrets Across Environments: Multiversal Secrecy

Different environments, different secrets. It's like having separate secret identities for work and your superhero life.

The Multiverse of Madness (or just your different environments)

  • Dev: Where mistakes happen, but it's okay
  • Staging: The dress rehearsal for your secrets
  • Production: Where the magic happens (and where mistakes are definitely not okay)

To manage this, you'll want different encryption keys for each environment. Here's how:


# For Dev
kubeseal --fetch-cert --controller-name=sealed-secrets-controller --controller-namespace=kube-system > dev-pub-cert.pem

# For Staging
kubeseal --fetch-cert --controller-name=sealed-secrets-controller --controller-namespace=kube-system > staging-pub-cert.pem

# For Production
kubeseal --fetch-cert --controller-name=sealed-secrets-controller --controller-namespace=kube-system > prod-pub-cert.pem

Now, when sealing secrets for different environments:


# For Dev
kubeseal --format yaml --cert dev-pub-cert.pem < secret.yaml > dev-sealed-secret.yaml

# For Staging
kubeseal --format yaml --cert staging-pub-cert.pem < secret.yaml > staging-sealed-secret.yaml

# For Production
kubeseal --format yaml --cert prod-pub-cert.pem < secret.yaml > prod-sealed-secret.yaml

Each environment gets its own uniquely encrypted secret. It's like having a different secret handshake for each of your superhero teams.

Rotating Secrets and Keys: The Circle of (Secret) Life

Even superheroes need to change their costumes sometimes. The same goes for your secrets and encryption keys.

When to rotate:

  • Regularly, as part of your security best practices
  • When you suspect a breach
  • When Dave from ops accidentally posts the keys on Slack (Classic Dave)

How to rotate a secret:

  1. Update your original Secret YAML
  2. Re-seal it with kubeseal
  3. Apply the new Sealed Secret to your cluster

Example: Rotating a database password


apiVersion: v1
kind: Secret
metadata:
  name: my-database-secret
type: Opaque
stringData:
  DB_PASSWORD: "evenmoresecretpassword456"


kubeseal --format yaml < updated-secret.yaml > updated-sealed-secret.yaml
kubectl apply -f updated-sealed-secret.yaml

Your applications will now use the new password without any downtime. Smooth operator!

Best Practices: The Superhero Code

Here's yours for Sealed Secrets:

  • Never, ever commit plaintext secrets to version control (I'm looking at you, intern)
  • Rotate your encryption keys regularly, like you rotate your tires (but more often)
  • Use RBAC to control who can encrypt/decrypt secrets (not everyone needs to be Nick Fury)
  • Monitor secret usage with Kubernetes audit logs (trust, but verify)

Tools and Alternatives: Choosing Your Superpower

Sealed Secrets isn't the only hero in town. Let's look at some other contenders:

  • HashiCorp Vault: The Swiss Army knife of secret management
  • AWS Secrets Manager: For when you're all in on AWS
  • Azure Key Vault: Microsoft's answer to "where do I put my secrets?"

Sealed Secrets shines in its simplicity and Kubernetes-native approach. But like choosing between Iron Man and Captain America, the best tool depends on your specific needs.

Troubleshooting: When Your Superpowers Fail

Even superheroes have off days. Here's how to deal with common Sealed Secrets issues:

Secret not decrypting?


kubectl get sealedsecrets
kubectl get events --field-selector involvedObject.kind=SealedSecret

Controller acting up?


kubectl logs deployment/sealed-secrets-controller -n kube-system

Mismatched keys?

Make sure you're using the right public key for the right cluster. It's like making sure you're in the right universe before trying to lift Thor's hammer.

Conclusion: With Great Power Comes Great Encryption

Sealed Secrets turns the nightmare of Kubernetes secret management into a dream. It's secure, it's scalable, and it lets you sleep at night knowing your secrets are actually secret.

Remember:

  • Seal your secrets before they touch version control
  • Use different keys for different environments
  • Rotate regularly
  • Monitor and audit

Now go forth and seal those secrets! Your cluster (and your blood pressure) will thank you.

For more information, check out the official Sealed Secrets documentation. And remember, with great secrets comes great responsibility!