You are browsing documentation for a version of Kuma that is not the latest release.
Looking for even older versions? Learn more.
Secret resource enables users to store sensitive data.
Sensitive information is anything a user considers non-public, e.g.:
- TLS keys
Secrets belong to a specific
Mesh resource, and cannot be shared across different
Policies use secrets at runtime.
Secret resources internally for certain operations,
for example when storing auto-generated certificates and keys when Mutual TLS is enabled.
On Kubernetes, Kuma under the hood leverages the native Kubernetes Secret resource to store sensitive information.
Kuma secrets are stored in the same namespace as the Control Plane with
type set to
apiVersion: v1 kind: Secret metadata: name: sample-secret namespace: kuma-system # Kuma will only manage secrets in the same namespace as the CP labels: kuma.io/mesh: default # specify the Mesh scope of the secret data: value: dGVzdAo= # Base64 encoded type: system.kuma.io/secret # Kuma will only manage secrets of this type
kubectl to manage secrets like any other Kubernetes resource.
echo "apiVersion: v1 kind: Secret metadata: name: sample-secret namespace: kuma-system labels: kuma.io/mesh: default data: value: dGVzdAo= type: system.kuma.io/secret" | kubectl apply -f - kubectl get secrets -n kuma-system --field-selector='type=system.kuma.io/secret' # NAME TYPE DATA AGE # sample-secret system.kuma.io/secret 1 3m12s
Kubernetes Secrets are identified with the
name + namespace format,
therefore it is not possible to have a
Secret with the same name in multiple meshes.
Meshes always belong to one Kuma CP that always runs in one Namespace.
In order to reassign a
Secret from one
Mesh to another
Mesh you need to delete the
Secret resource and create it in another
data field of a Kuma
Secret is a Base64 encoded value.
base64 command in Linux or macOS to encode any value in Base64:
# Base64 encode a file cat cert.pem | base64 # or Base64 encode a string echo "value" | base64
Access to the Secret HTTP API
Secret API requires authentication. Consult Accessing Admin Server from a different machine for how to configure remote access.
Scope of the Secret
Kuma provides two types of Secrets.
Mesh-scoped Secrets are bound to a given Mesh. Only this kind of Secrets can be used in Mesh Policies like Provided CA or TLS setting in External Service.
apiVersion: v1 kind: Secret metadata: name: sample-secret namespace: kuma-system labels: kuma.io/mesh: default # specify the Mesh scope of the secret data: value: dGVzdAo= type: system.kuma.io/secret
Global-scoped Secrets are not bound to a given Mesh and cannot be used in Mesh Policies.
Global-scoped Secrets are used for internal purposes.
You can manage them just like the regular secrets using
Notice that the
type is different and
kuma.io/mesh label is not present.
apiVersion: v1 kind: Secret metadata: name: sample-secret namespace: kuma-system data: value: dGVzdAo= type: system.kuma.io/global-secret
Here is an example of how you can use a Kuma
Secret with a
provided Mutual TLS backend.
The examples below assumes that the
Secret object has already been created beforehand.
type: Mesh name: default mtls: backends: - name: ca-1 type: provided config: cert: secret: my-cert # name of the Kuma Secret key: secret: my-key # name of the Kuma Secret