Security

    Kuma uses a built-in CA (Certificate Authority) to issue certificates for dataplanes. The root CA certificate is unique for each mesh in the system. On Kubernetes, the root CA certificate is stored as a Kubernetes Secret. On Universal, we leverage the same storage (Postgres) that is used for storing policies. Certificates for dataplanes are ephemeral, re-created on dataplane restart and never persisted on disk.

    Dataplane certificates generated by Kuma are X.509 certificates that are compliant. The SAN of certificate is set to

    Kuma also supports external CA. By changing the ca in the mesh resource to provided, you can use a CA of your choice.

    To manage external CAs after you update the mesh resource, kumactl now supports a new command: kumactl manage ca. With this new command, you can do add and delete certificates.

    For further details refer to Mutual TLS policy.

    On Kubernetes, a dataplane proves its identity by leveraging that is mounted in every pod.

    On Universal, a dataplane must be explicitly configured with a unique security token (Dataplane Token) that will be used to prove its identity. Dataplane Token is a signed JWT tokenSecurity - 图5 that the carries dataplane name and name of the mesh it’s allowed to join to. It is signed by an RSA key auto-generated by the control plane on first run. Tokens are not stored in the control plane, the only thing that is stored is a signing key that is used to verify if a token is valid.

    You can generate token either by REST API

      or by using kumactl

      The token should be stored in a file and then used when starting kuma-dp

      1. $ kuma-dp run \
      2.   --name=dp-echo-1 \
      3.   --mesh=default \
      4.   --cp-address=http://127.0.0.1:5681 \

      Accessing Admin Server from a different machine

      1. Enable public server by setting KUMA_ADMIN_SERVER_PUBLIC_ENABLED to true. Make sure to specify hostname which can be used to access Kuma from other machine via KUMA_GENERAL_ADVERTISED_HOSTNAME.
      2. Generate certificate for the HTTPS Admin Server and set via KUMA_ADMIN_SERVER_PUBLIC_TLS_CERT_FILE and KUMA_ADMIN_SERVER_PUBLIC_TLS_KEY_FILE config environment variable. For generating self signed certificate you can use kumactl
      1. Pick a public interface on which HTTPS server will be exposed and set it via KUMA_ADMIN_SERVER_PUBLIC_INTERFACE. Optionally pick the port via KUMA_ADMIN_SERVER_PUBLIC_PORT. By default, it will be the same as the port for the HTTP server exposed on localhost.
      1. $ kumactl generate tls-certificate --cert-file=/path/to/cert --key-file=/path/to/key --type=client
      1. Configure with client certificate.

      Once a dataplane has proved its identity, it will be allowed to fetch its own identity certificate and a root CA certificate of the mesh. When establishing a connection between two dataplanes each side validates each other dataplane certificate confirming the identity using the root CA of the mesh.

      mTLS is not enabled by default. To enable it, apply proper settings in Mesh policy. Additionally, when running on Universal you have to ensure that every dataplane in the mesh has been configured with a Dataplane Token.

      When mTLS is enabled, every connection between dataplanes is denied by default, so you have to explicitly allow it using .

      Since on Universal, the secrets such as “provided” CA’s private key, are stored in Postgres, a connection between Postgres and Kuma CP should be secured with TLS. To secure the connection, first pick the security mode using KUMA_STORE_POSTGRES_TLS_MODE. There are several modes:

      • disable - is not secured with TLS (secrets will be transmitted over network in plain text).
      • verifyNone - the connection is secured but neither hostname, nor by which CA the certificate is signed is checked.
      • verifyCa - the connection is secured and the certificate presented by the server is verified using the provided CA.
      • verifyFull - the connection is secured, certificate presented by the server is verified using the provided CA and server hostname must match the one in the certificate.

      The CA for verification server’s certificate can be set using KUMA_STORE_POSTGRES_TLS_CA_PATH.

      1. # TYPE  DATABASE        USER            ADDRESS                 METHOD
      2. hostssl all             all             0.0.0.0/0               password

      You can also provide client key and certificate for mTLS using KUMA_STORE_POSTGRES_TLS_CERT_PATH and KUMA_STORE_POSTGRES_TLS_KEY_PATH. This pair can be used for auth-method described here.