Bitnami Sealed Secret — New way to Encrypt Kubernetes Secrets

Sharadhi S S
5 min readJul 15, 2022

--

Bitnami SealedSecret with Kubernetes

Nowadays most companies use Kubernetes, a container orchestration tool to deploy applications. Managing secret in Kubernetes is difficult. There will be a lot of secrets for different applications. We don’t want to make the secret available in this case. We store Kubernetes manifest files on GitHub. What about secrets? Are you not storing any secrets in git? It would be silly to store secrets in git. Right?

But what if we can store secrets in git? What if we make Git a complete source of truth?

How we normally use Kubernetes Secret?

Let us understand what happens if we store secrets in git. We will commit Kubernetes secret manifest to git. Say we want to store a token called foobar as a secret. As Kubernetes secrets are base64 encoded, what we normally do is encode the foobar to base64.

echo -n foobar | base64
base64 encoded value of foobar

And we add this to Kubernetes manifest file. Normally Kubernetes secret file looks like this:

Kubernetes secret file base64 encoded

If we push this file to GitHub and some attackers get this secret. They can run a simply run command:

echo -n Zm9vYmFy | base64 –decode
base64 decoded value

Oh no!! they got the secret. Your secret is revealed to everyone as it was encoded not encrypted. So, we should not use base64 secret while pushing to git.

As a solution to this, we have many other tools such as:

  • Bitnami Sealed Secret
  • HashiCorp Vault
  • Azure Key Vault
  • Ansible Vault
  • AWS Security Manager

But let us put our attention to Bitnami Sealed Secret. If we encrypt our Kubernetes secret into a sealed secret, we can push our secret also git and we can achieve a single source of truth i.e., Git. A sealed secret is an encrypted secret, that can be decrypted only inside the cluster. The Sealed Secret is safe to share publicly, upload to git repositories, post to Twitter, etc. Once the SealedSecret is safely uploaded to the target Kubernetes cluster, the sealed secrets controller will decrypt it and recover the original Secret.

How does Sealed Secret work?

Sealed secrets by bitnami use asymmetric encryption. The sealed secret consists of two main components:

  • A Controller that runs in the cluster, implements Kubernetes sealed secret API object.
  • Kubeseal tool to encrypt (YAML or JSON) in the cluster.
Asymmetric Encryption

Here client gets the public key from the cluster and encrypts it. This is how we get a sealed secret manifest file. Another component is a controller which sees this encrypted data and uses the private key in the cluster and decrypts it. So, in sealed secret Kubeseal is installed as a client-side component, and a Controller is installed as a server-side component.

Installation of kubeseal and controller

As a prerequisite, make sure you have minikube installed and running. To install minikube follow this:

Step 1: We need to install a Controller to implement a sealed secret API. The command to install is:

kubectl apply --filename https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.18.0/controller.yaml

Step 2: We also need to install kubeseal to encrypt our secret. Download the latest version of kubeseal using this command:

sudo wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.17.2/kubeseal-0.17.2-linux-amd64.tar.gz

Extract and execute the file:

sudo tar xzvf kubeseal-0.17.2-linux-amd64.tar.gz
sudo install -m 755 kubeseal /usr/local/bin/kubeseal

In macOS environments, it can be easily installed by using HomeBrew,

brew install kubeseal

Implementation of sealed secret

We normally use kubectl create secret command to generate Kubernetes secret. We can pass this Kubernetes secret to kubeseal. Kubeseal will take the output of this command and convert it into encrypted SealedSecret. For demonstration purposes, let us use dry-run first, which creates a file in local and it will not upload anything to the cluster. and after that let’s apply that file to the Kubernetes cluster.

Say we want to create foo=bar as secret.

kubectl --namespace default \
create secret \
generic mysecret \
--dry-run=client \
--from-literal foo=bar \
--output json \
| kubeseal \
| tee mysecret.yaml

The output of this file when we run in CLI will be:

Encrypted secret

This is an encrypted file. Even if attackers find this file, they will not be able to retrieve the secret outside the cluster.

Let's create this secret in the minikube cluster:

kubectl create \
--filename mysecret.yaml

The secret will be created.

The output of Sealed Secret Created

After encryption, we can identify that kubeseal has created a CRD resource with the encrypted Kubernetes secret. Now, we applied encrypted secret. Let’s check how that secret is stored in the cluster.

Inside cluster file will be decrypted

We applied the encrypted secret, and the controller in the cluster made use of the private key and decrypted the secret, and applied it to the cluster. If you see, the secret is base64 encoded inside the cluster. We can access this only inside the cluster.

Now you can make use of this SealedSecret instead of plane Kubernetes secret.

Conclusion

This article is about how we can use SealedSecret in automated pipelines. We can push this secret to GitHub as this secret can only be decrypted by a controller which runs inside the cluster. Once it’s applied Sealed secret will work the same as other secrets. For more understanding you can go for official documentation here:

If you liked this article, please consider donating whatever amount you can using this link. It would mean a lot.

--

--

Sharadhi S S

DevOps Engineer with expertise in CI/CD, cloud platform, containerization, and automation Passionate about driving efficient and secure delivery.