Kuma provides a built-in interface to store sensitive information such as TLS keys and tokens that can be used later on by any policy at runtime. This functionality is being implemented by introducing a Secret resource.
Secrets belong to a specific Mesh resource, and cannot be shared across different Meshes.
Kuma will also leverage Secret resources internally for certain operations, for example when storing auto-generated certificates and keys when Mutual TLS is enabled.
Kuma secrets are stored in the same namespace as the Control Plane with type valued as system.kuma.io/secret:
apiVersion: v1
kind: Secret
metadata:name: sample-secret
namespace: kuma-system # Kuma will only manage secrets in the same namespace as the CPlabels:kuma.io/mesh: default # specify the Mesh scope of the secret data:value: dGVzdAo= # bytes encoded in Base64type: system.kuma.io/secret # Kuma will only manage secrets of this type
1 2 3 4 5 6 7 8 9 10
Use 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14
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 (since multiple Meshes always belong to one Kuma CP that always runs in one Namespace).
In order to reassign a Secret to another Mesh you need to delete the Secret resource and apply it again.
A Secret is a simple resource that stores specific data:
The data field of a Kuma Secret should always be a Base64 encoded value. You can use the base64 command in Linux or macOS to encode any value in Base64:
# Base64 encode a filecat cert.pem | base64
# or Base64 encode a stringecho"value"| base64
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
1 2 3 4 5 6 7 8 9 10
type: Secret
name: sample-secret
mesh: default # specify the Mesh scope of the secretdata: dGVzdAo=
Global-scoped Secrets are not bound to a given Mesh and cannot be used in Mesh Policies. They are used for internal purposes.
You can manage them just like the regular secrets using kumactl or kubectl.
Notice that the type is different and kuma.io/mesh label is not present.
Here is example of how you can use a Kuma Secret with a providedMutual TLS backend.
The examples below assume that the Secret object has already been created before-hand.
type: Mesh
name: default
mtls:backends:-name: ca-1type: provided
config:cert:secret: my-cert # name of the Kuma Secretkey:secret: my-key # name of the Kuma Secret
1 2 3 4 5 6 7 8 9 10 11
apiVersion: kuma.io/v1alpha1
kind: Mesh
metadata:name: default
spec:mtls:backends:-name: ca-1type: provided
config:cert:secret: my-cert # name of the Kubernetes Secretkey:secret: my-key # name of the Kubernetes Secret