Sealed Secrets
Use Sealed Secrets on CoreWeave Cloud
Bitnami's Sealed Secrets solution can be used to encrypt secrets such that they can safely be managed and shared using git.
kubeseal
creates a SealedSecret
resource, which can then only be decrypted by the controller running in the cluster. Not even the original creator of the Secret is then able to extract the original Secret from the SealedSecret
resource.
Sealed Secrets are composed of two parts:
A cluster-side controller/operator
A client-side utility:
kubeseal
A cluster-side controller for Sealed Secrets is already installed in CoreWeave Cloud, so clients may use Sealed Secrets simply by installing the client-side utility, kubeseal
.
Additional Resources
More information on Sealed Secrets are available in Bitnami's Sealed Secrets repository.
How it works
Sealed Secrets are encoded in a SealedSecret
resource, which looks like this:
Once "unsealed," this the secret will be revealed as a normal Kubernetes secret, similar to this:
This normal Kubernetes secret will appear in the cluster after a few seconds you can use it as you would use any secret that you would have created directly (e.g. reference it from a Pod
).
Install kubeseal
To install kubeseal, you may use any of the following methods:
Homebrew
The kubeseal
client is also available on homebrew:
MacPorts
The kubeseal
client is also available on MacPorts:
Linux
The kubeseal
client can be installed on Linux, using the below commands:
where release-tag
is the version tag of the kubeseal release you want to use. For example: v0.18.0
.
From source
The latest client tool can be installed into $GOPATH/bin
using:
It is possible to specify a release tag or a commit SHA hash instead of main
. The go install
command will place the kubeseal
binary at $GOPATH/bin
:
Create a Sealed Secret
First, create a Secret inside either a JSON or YAML file. In this example, a file containing a JSON secret (the default format for Sealed Secrets) is created via the command line. This example also uses --dry-run
for preview purposes:
Next, kubeseal
is used to encrypt the JSON-encoded secret. First, kubeseal
reads the namespace from the input secret, accepts an explicit --namespace
argument, and then uses the kubectl
default namespace, in that order. Any labels or annotations on the original Secret
are preserved, but not automatically reflected in the SealedSecret
.
At this point, the secret contents of mysealedsecret.json
are encrypted, so the file is safe to share via git or any other method. The secret can then be added as a Kubernetes secret using kubectl create
:
Once deployed, the secret can be viewed using kubectl get
:
Important
SealedSecret
and Secret
must have the same namespace and name.
Please also note:
By design, this scheme does not authenticate the user. In other words, anyone can create a
SealedSecret
containing anySecret
they like (provided the namespace/name matches). It is up to your existing config management workflow, cluster RBAC rules, etc to ensure that only the intendedSealedSecret
is uploaded to the cluster. The only change from existing Kubernetes is that the contents of theSecret
are now hidden while outside the cluster.
Example
The following example files demonstrate what it looks like to actually position Sealed Secrets inside a Helm context. The sample Helm template file provided here, called sealedsecrets.yaml
, consumes the Sealed Secret values in the example values file, called values-prod.yaml
.
The template file:
The corresponding values file:
Last updated