Sealed Secrets are "one-way" encrypted K8s Secrets that can be created by anyone, but can only be decrypted by the controller running in the target cluster recovering the original object.

• TL;DR
• Introduction
• Prerequisites
• Installing the Chart
• Uninstalling the Chart
• Parameters
  • Common parameters
  • Sealed Secrets Parameters
  • Traffic Exposure Parameters
  • Other Parameters
  • Metrics parameters
• Using kubeseal
• Configuration and installation details
• Troubleshooting
• Upgrading
  • To 2.0.0

$ helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
$ helm install my-release sealed-secrets/sealed-secrets

Bitnami charts for Helm are carefully engineered, actively maintained and are the quickest and easiest way to deploy containers on a Kubernetes cluster that are ready to handle production workloads.

This chart bootstraps a Sealed Secret Controller Deployment in Kubernetes using the Helm package manager.

Bitnami charts can be used with Kubeapps for the deployment and management of Helm Charts in clusters.

• Kubernetes 1.16+
• Helm 3.1.0

To install the chart with the release name my-release:

helm install my-release sealed-secrets/sealed-secrets

The command deploys the Sealed Secrets controller on the Kubernetes cluster in the default configuration. The Parameters section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

To uninstall/delete the my-release deployment:

helm delete my-release

The command removes all the Kubernetes components associated with the chart and deletes the release.

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

$ helm install my-release \
  --set resources.requests.cpu=25m \
    sealed-secrets/sealed-secrets

The above command sets the resources.requests.cpu parameter to 25m.

Alternatively, a YAML file that specifies the values for the above parameters can be provided while installing the chart. For example,

helm install my-release -f values.yaml sealed-secrets/sealed-secrets

Install the kubeseal CLI by downloading the binary from sealed-secrets/releases.

Fetch the public key by passing the release name and namespace:

kubeseal --fetch-cert \
--controller-name=my-release \
--controller-namespace=my-release-namespace \
> pub-cert.pem

Read about kubeseal usage on sealed-secrets docs.

NOTE: the helm chart by default installs the controller with the name sealed-secrets, while the kubeseal command line interface (CLI) tries to access the controller with the name sealed-secrets-controller. You can explicitly pass --controller-name to the CLI:

kubeseal --controller-name sealed-secrets <args>

Alternatively, you can override fullnameOverride on the helm chart install.

• In the case that serviceAccount.create is false and rbac.create is true it is expected for a ServiceAccount with the name serviceAccount.name to exist in the same namespace as this chart before the installation.
• If rbac.create is `true, by default clusterRoles are created. To switch to namespaced Roles:
  1. set the required namespaces in additionalNamespaces
  2. set rbac.clusterRole to false
  3. set rbac.namespacedRoles to true
• If serviceAccount.create is true there cannot be an existing service account with the name serviceAccount.name.
• If a secret with name secretName does not exist in the same namespace as this chart, then on install one will be created. If a secret already exists with this name the keys inside will be used.
• OpenShift: unset the runAsUser and fsGroup like this when installing in a custom namespace:

podSecurityContext:
  fsGroup:

containerSecurityContext:
  runAsUser:

Find more information about how to deal with common errors related to Bitnami's Helm charts in this troubleshooting guide.

A major refactoring of the chart has been performed to adopt several common practices for Helm charts. Upgrades from previous chart versions should work, however, the values structure experienced several changes and you'll have to adapt your custom values/parameters so they're aligned with the new structure. For instance, these are a couple of examples:

• controller.create renamed as createController.
• securityContext.* parameters are deprecated in favor of podSecurityContext.*, and containerSecurityContext.* ones.
• image.repository changed to image.registry/image.repository.
• ingress.hosts[0] changed to ingress.hostname.

Consult the Parameters section to obtain more info about the available parameters.

On November 13, 2020, Helm v2 support was formally finished, this new major version is no longer compatible with Helm v2.