Kuma Star

Careful!

You are browsing documentation for a version of Kuma that is not the latest release.

Looking for even older versions? Learn more.

Secure access accross services

This page explains how secure access is provided across a Kuma deployment:

Kuma stores autogenerated certificates and other files in a working directory. The default value for this directory is $HOME/.kuma. You can change the working directory by setting the KUMA_GENERAL_WORK_DIR environment variable.

This section is not to be confused with the mTLS policy that you can apply to a Mesh to secure service-to-service traffic.

Data plane proxy to control plane communication

A data plane proxy connects to the control plane for its configuration, including mTLS certificates described in the following sections.

Encrypted communication

Because the data plane proxy and the control plane exchange sensitive information, the communication needs to be encrypted by TLS. By default, the control plane’s server that is consumed by the data plane proxy is secured by TLS with autogenerated certificates.

It’s recommended that the data plane proxy verifies the identity of the control plane. To do so, data plane proxies need to obtain the CA that was used to generate the certificate by which the control plane’s server is secured. Note, this CA is not the same CA for service-to-service communication.

To override autogenerated certificates

If overridden, Kuma uses the certificates to protect not only data plane proxy to control plane traffic but also user to control plane traffic and control plane to control plane traffic.

1) Prepare certificates

Generate a TLS pair with a PKI of your choice and store it in PEM-encoded format in /tmp/tls.crt, /tmp/tls.key. Store the CA that was used to sign this pair in /tmp/ca.crt.

You can also use kumactl to generate self-signed certs:

kumactl generate tls-certificate \
  --type=server \
  --hostname=<KUMA_CP_DNS_NAME> \
  --cert-file=/tmp/tls.crt \
  --key-file=/tmp/tls.key

Since “tls.crt” is a self-signed cert, it’s also a CA:

cp /tmp/tls.crt /tmp/ca.crt

2) Configure the control plane with generated certs:

Create a secret in the namespace where the control plane is installed:

kubectl create secret generic general-tls-certs -n kuma-system \
  --from-file=tls.crt=/tmp/tls.crt \
  --from-file=tls.key=/tmp/tls.key \
  --from-file=ca.crt=/tmp/ca.crt

Point to this secret when installing Kuma:

kumactl install control-plane \
  --set "controlPlane.tls.general.secretName=general-tls-certs" \
  --set "controlPlane.tls.general.caBundle=$(cat /tmp/ca.crt | base64)" \
  | kubectl apply -f -

The data plane proxy Injector in the control plane automatically provides the CA to the Kuma DP sidecar so Kuma DP can confirm the control plane identity.

Authentication

See Data plane proxy authentication and Zone proxy authentication .

Prometheus to control plane communication

You can enable TLS on the Monitoring Assignment Discovery Service. By default, it uses the same certificate used for CP to DP communication. This is the certificate configured with the --tls-general options. You can enable it by using the KUMA_MONITORING_ASSIGNMENT_SERVER_TLS_ENABLED=true environment variable.

Create a secret in the namespace where the control plane is installed:

kubectl create secret generic general-tls-certs -n kuma-system \
  --from-file=tls.crt=/tmp/tls.crt \
  --from-file=tls.key=/tmp/tls.key \
  --from-file=ca.crt=/tmp/ca.crt

Point to this secret when installing Kuma:

kumactl install control-plane \
  --set "controlPlane.tls.general.secretName=general-tls-certs" \
  --set "controlPlane.tls.general.caBundle=$(cat /tmp/ca.crt | base64)" \
  --set "controlPlane.envVars.KUMA_MONITORING_ASSIGNMENT_SERVER_TLS_ENABLED=true" \
  | kubectl apply -f -

Now you can configure Kuma’s Prometheus SD with the correct TLS configuration using the Prometheus docs.

User to control plane communication

Users and automation tools can interact with the control plane via the API Server using tools like curl or kumactl. API Server is exposed by default on :5681 on HTTP and :5682 on HTTPS.

Encrypted communication

The API Server HTTPS server is secured by default by autogenerated certificates.

To override autogenerated certificates.

1) Prepare certificates. Generate TLS pair with a PKI of your choice and store it in PEM-encoded format in /tmp/tls.crt, /tmp/tls.key. Store the CA that was used to sign this pair in /tmp/ca.crt

You can also use kumactl to generate self-signed certs:

  kumactl generate tls-certificate \
    --type=server \
    --hostname=<KUMA_CP_DNS_NAME> \
    --cert-file=/tmp/tls.crt \
    --key-file=/tmp/tls.key

Since “tls.crt” is a self-signed cert, it’s also a CA:

  cp /tmp/tls.crt /tmp/ca.crt

2) Configure the control plane with generated certificates

Create a secret in the namespace in which the control plane is installed:

kubectl create secret tls api-server-tls -n kuma-system \
  --cert=/tmp/tls.crt \
  --key=/tmp/tls.key

Point to this secret when installing Kuma:

kumactl install control-plane \
  --set "controlPlane.tls.apiServer.secretName=api-server-tls" \
  | kubectl apply -f -

If you receive an error like the following, make sure you are using a supported PEM certificate and that the certificate doesn’t contain incomplete or corrupted data:

  Warning  FailedCreate  3m39s (x18 over 14m)  replicaset-controller  Error creating: Internal error occurred: failed calling webhook "namespace-kuma-injector.kuma.io": could not get REST client: unable to load root certificates: unable to parse bytes as PEM block

3) Configure secure connection using the kumactl CLI:

  kumactl config control-planes add \
    --name=<NAME> \
    --address=https://<KUMA_CP_DNS_NAME>:5682 \
    --ca-cert-file=/tmp/ca.crt \

You can also hide the HTTP version of API Server by binding it to localhost KUMA_API_SERVER_HTTP_INTERFACE: 127.0.0.1 or by disabling it altogether KUMA_API_SERVER_HTTP_ENABLED: false

Authentication

See API Server authentication .

Control plane to control plane (Multizone)

A zone control plane connects to a global control plane for policies configuration.

Encrypted communication

Because the global control plane and the zone control plane exchange sensitive information, the communication needs to be encrypted by TLS. By default, the global control plane’s server that is consumed by the zone control plane is secured by TLS with autogenerated certificates.

It’s recommended that the zone control plane verifies the identity of the global control plane. To do so, zone control planes need to obtain the CA that was used to generate the certificate by which the control plane’s server is secured.

To override autogenerated certificates

1) Prepare certificates

Generate TLS pair with a PKI of your choice and store it in PEM-encoded format in /tmp/tls.crt, /tmp/tls.key. Store the CA that was used to sign this pair in /tmp/ca.crt

You can also use kumactl to generate self-signed certs:

kumactl generate tls-certificate \
  --type=server \
  --hostname=<CROSS_ZONE_KUMA_CP_DNS_NAME> \
  --cert-file=/tmp/tls.crt \
  --key-file=/tmp/tls.key

Since “tls.crt” is a self-signed cert, it’s also a CA:

cp /tmp/tls.crt /tmp/ca.crt

2) Configure global control plane

Create a secret in the namespace where the global control plane is installed:

kubectl create secret tls kds-server-tls -n kuma-system \
  --cert=/tmp/tls.crt \
  --key=/tmp/tls.key

Point to this secret when installing the global control plane:

kumactl install control-plane \
  --set "controlPlane.tls.kdsGlobalServer.secretName=kds-server-tls" \
  | kubectl apply -f -

3) Configure the zone control plane

Create a secret in the namespace where the zone control plane is installed:

kubectl create secret generic kds-ca-certs -n kuma-system \
  --from-file=ca.crt=/tmp/ca.crt

Point to this secret when installing the zone control plane:

kumactl install control-plane \
  --set "controlPlane.tls.kdsZoneClient.secretName=kds-ca-certs" \
  | kubectl apply -f -

Authentication

Define firewall rules on the global control plane to only accept connections from known IPs of the zone control planes.

Third-party extensions, cloud implementations or commercial offerings may be extending the authentication support.