Skip to main content
In this guide you’ll deploy Bitnami Sealed Secrets into a Kubernetes cluster using Argo CD. We’ll reference the official Helm chart on Artifact Hub and walk through both a direct Helm install and an Argo CD Application-based deployment. Finally, you’ll install the kubeseal CLI so you can create SealedSecrets that are safe to store in Git — enabling a GitOps workflow.
The image shows a webpage for "sealed-secrets" on Artifact Hub, detailing a Helm chart for a sealed-secrets controller with options to install, templates, default values, and a changelog. It also features a banner for KubeCon + CloudNativeCon India 2023.
The Artifact Hub page lists the Helm repository URL, available chart versions, values and installation instructions. You can either install the chart locally with Helm or configure Argo CD to fetch the Helm chart and keep it synchronized.

​
Option A — Install locally with Helm

Add the Bitnami Labs repo and install the sealed-secrets chart. Pick a chart version that matches your requirements (example below uses 2.17.3): 
helm repo add bitnami-labs https://bitnami-labs.github.io/sealed-secrets/
helm repo update
helm install my-sealed-secrets bitnami-labs/sealed-secrets --version 2.17.3
Tip: override chart values by creating a values.yaml file and passing -f values.yaml to helm install. Configure an Argo CD Application that points to the Bitnami Labs Helm repo so Argo CD can fetch and sync the chart automatically. Steps in the Argo CD UI:
  • Set Source Type to Helm and paste the Helm repository URL: https://bitnami-labs.github.io/sealed-secrets/
  • Select the sealed-secrets chart and pick the desired chart version (for example, 2.17.0 or 2.17.3)
  • Set the Destination cluster and choose the target namespace (this example uses kube-system)
  • Optionally enable Auto-Sync so changes in the chart are applied automatically
The image shows a software configuration interface for an application called "sealed-secrets" in ArgoCD, with options for setting sync policies and other settings like schema validation and namespace creation.
After you create the Application, Argo CD will fetch the chart, render templates (using chart defaults unless you override them), and deploy the resources to the target namespace. The sealed-secrets Helm chart typically creates:
Resource TypePurpose
Deployment / PodsRuns the sealed-secrets controller
ServicesController and metrics endpoints
RBACServiceAccount, Roles, and RoleBindings required
CRDsCustomResourceDefinitions for SealedSecret
TLS SecretController keypair (public key is used by kubeseal)
When sync completes in Argo CD, the Application should show a healthy and synced status.
The image shows an Argo CD interface with two applications, "highway-animation" and "sealed-secrets," both displaying a status of "Healthy" and "Synced." It includes options to sync, refresh, or delete the applications.
You can also inspect the Application and its resources in the Argo CD UI.
The image shows a user interface of Argo CD, displaying the "sealed-secrets" application with a healthy and synced status, along with its related resources and configurations.

​
Verify the controller in Kubernetes

Use kubectl to confirm the controller, services and the TLS secret are present in the target namespace (example uses kube-system): 
# List sealed-secrets pods in kube-system
kubectl -n kube-system get pods | grep -i sealed

# List related resources
kubectl -n kube-system get all | grep -i sealed

# List secrets (sealed-secrets publishes a TLS secret used by the controller)
kubectl -n kube-system get secret | grep -i sealed
Example output (names, timestamps and UIDs will vary): 
pod/sealed-secrets-545f6845c-sx9bn       1/1     Running   0          34s
service/sealed-secrets                   ClusterIP   10.104.148.215   <none>        8080/TCP   35s
service/sealed-secrets-metrics           ClusterIP   10.97.142.113    <none>        8081/TCP   35s
deployment.apps/sealed-secrets           1/1     1            1          34s
replicaset.apps/sealed-secrets-545f6845c  1/1     34s

sealed-secrets-keykvrhb                   kubernetes.io/tls

​
Install the kubeseal CLI

The kubeseal client encrypts Kubernetes Secret manifests using the controller’s public key. The output is a SealedSecret resource that can be safely stored in Git and applied to the cluster; only the controller can decrypt it. You can find releases on the Bitnami Labs Sealed Secrets GitHub repo: bitnami-labs/sealed-secrets.
The image is a screenshot of a GitHub page for the project "Sealed Secrets" for Kubernetes, showing installation and usage documentation.
The image shows a GitHub repository page for "bitnami-labs/sealed-secrets," displaying a list of branches/tags and recent commits. The repository is described as a Kubernetes controller for encrypted secrets.
Install a specific kubeseal version (replace 0.30.0 with the version you want): 
# Example: install a specific version
KUBESEAL_VERSION='0.30.0'
curl -L -o kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz \
  "https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION}/kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz"
tar -xvzf kubeseal-${KUBESEAL_VERSION}-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal
Or fetch and install the latest release automatically (requires jq): 
# Install latest kubeseal release (requires jq)
TAG=$(curl -s https://api.github.com/repos/bitnami-labs/sealed-secrets/releases/latest | jq -r .tag_name)
# Strip leading "v" from tag to get version (e.g., v0.30.0 -> 0.30.0)
VERSION=${TAG#v}
curl -L -o kubeseal-${VERSION}-linux-amd64.tar.gz \
  "https://github.com/bitnami-labs/sealed-secrets/releases/download/${TAG}/kubeseal-${VERSION}-linux-amd64.tar.gz"
tar -xvzf kubeseal-${VERSION}-linux-amd64.tar.gz kubeseal
sudo install -m 755 kubeseal /usr/local/bin/kubeseal
Verify the installed client: 
kubeseal --version
# Example output:
# kubeseal version: 0.30.0
Ensure your kubeconfig points to the cluster where the sealed-secrets controller is installed before using kubeseal. The client fetches the controller’s public key from the cluster to create SealedSecrets that only the controller can decrypt.

​
What you now have

  • Bitnami Sealed Secrets controller deployed in your cluster (via Helm or Argo CD)
  • kubeseal CLI installed locally to generate SealedSecrets
  • The foundation for a GitOps workflow: encrypt plain Secrets into SealedSecrets and commit them to Git; the sealed-secrets controller will decrypt and create Kubernetes Secrets in-cluster
If you’d like, I can add a sample workflow showing how to create a Secret locally, seal it with kubeseal, and commit the resultant SealedSecret to Git for automatic deployment.

Watch Video