You are browsing documentation for a version of Kuma that is not the latest release.
Looking for even older versions? Learn more.
Control Plane Configuration
Modifying the configuration
There are 2 ways to configure the control plane:
- Environment variables
- YAML configuration file
Environment variables take precedence over YAML configuration.
All possible configuration and their default values are in the
kuma-cp reference doc.
Environment variables usually match the yaml path by replacing
_, capitalizing names and prefixing with KUMA.
For example the yaml path:
store.postgres.port is the environment variable:
On Kubernetes, you can override the configuration with the
envVars field. For example, to configure the refresh interval for configuration with the data plane proxy, specify:
kumactl install control-plane \ --set "controlPlane.envVars.KUMA_XDS_SERVER_DATAPLANE_CONFIGURATION_REFRESH_INTERVAL=5s" \ --set "controlPlane.envVars.KUMA_XDS_SERVER_DATAPLANE_STATUS_FLUSH_INTERVAL=5s" \ | kubectl apply -f -
Or you can create a
values.yaml file with:
controlPlane: envVars: KUMA_XDS_SERVER_DATAPLANE_CONFIGURATION_REFRESH_INTERVAL: 5s KUMA_XDS_SERVER_DATAPLANE_STATUS_FLUSH_INTERVAL: 5s
and then specify it in the helm install command:
helm install -f values.yaml kuma/kuma
If you have a lot of configuration you can just write them all in a YAML file and use:
helm install kuma kuma/kuma --set-file controlPlane.config=cp-conf.yaml
The value of the configmap
kuma-control-plane-config is now the content of
If you configure
kuma-cp with a YAML file, make sure to provide only values that you want to override.
Otherwise, upgrading Kuma might be harder, because you need to keep track of your changes when replacing this file on every upgrade.
Inspecting the configuration
There are many ways to see your control plane configuration:
- In the
kuma-cplogs, the configuration is logged on startup.
- The control plane API server has an endpoint:
- The GUI exposes the configuration on the Diagnostic tab, accessible in the lower left corner.
- In a multi-zone deployment, the zone control plane sends its configuration to the global control plane. This lets you inspect all configurations with
kumactl inspect zones -oyamlor in the GUI.
When Kuma (
kuma-cp) is up and running it needs to store its state on Universal it’s Postgres, for Kubernetes it’s leveraging Kubernetes custom resource definitions.
Thus state includes the policies configured, the data plane proxy status, and so on.
Kuma supports a few different types of store.
You can configure the backend storage by setting the
KUMA_STORE_TYPE environment variable when running the control plane.
The following backends are available:
The configuration to set the store is the yaml path
store.type or the environment variable
Kuma stores all the state in the underlying Kubernetes cluster.
This is only usable if the control plane is running in Kubernetes mode. You can’t manage Universal CPPs from a control plane with a Kubernetes store.
Kuma stores all the state in-memory. Restarting Kuma will delete all the data, and you cannot have more than one control plane instance running.
Memory is the default memory store when running in Universal mode and is only available in Universal mode.
Don’t use this store in production because the state isn’t persisted.
Kuma stores all the state in a PostgreSQL database. This can only be used when running in Universal mode.
KUMA_STORE_TYPE=postgres \ KUMA_STORE_POSTGRES_HOST=localhost \ KUMA_STORE_POSTGRES_PORT=5432 \ KUMA_STORE_POSTGRES_USER=kuma-user \ KUMA_STORE_POSTGRES_PASSWORD=kuma-password \ KUMA_STORE_POSTGRES_DB_NAME=kuma \ kuma-cp run
For great availability and low maintenance cost you can use a PostgreSQL database offered by any cloud vendor.
Connection between Postgres and Kuma CP should be secured with TLS.
The following modes are available to secure the connection to Postgres:
disable: the connection 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 mode is configured with the
KUMA_STORE_POSTGRES_TLS_MODE environment variable.
The CA used to verify the server’s certificate is configured with the
KUMA_STORE_POSTGRES_TLS_CA_PATH environment variable.
After configuring the above security settings in Kuma, we also have to configure Postgres’
pg_hba.conf file to restrict unsecured connections.
Here is an example configuration that allows only TLS connections and requires a username and password:
# TYPE DATABASE USER ADDRESS METHOD hostssl all all 0.0.0.0/0 password
You can also provide a client key and certificate for mTLS using the
This pair can be used in conjunction with the
cert auth-method described in the Postgres documentation.
To provide easy upgrades between Kuma versions there is a migration system for the Postgres DB schema.
When upgrading to a new version of Kuma, run
kuma-cp migrate up so the new schema is applied.
KUMA_STORE_TYPE=postgres \ KUMA_STORE_POSTGRES_HOST=localhost \ KUMA_STORE_POSTGRES_PORT=5432 \ KUMA_STORE_POSTGRES_USER=kuma-user \ KUMA_STORE_POSTGRES_PASSWORD=kuma-password \ KUMA_STORE_POSTGRES_DB_NAME=kuma \ kuma-cp migrate up
Kuma CP at the start checks if the current DB schema is compatible with the version of Kuma you are trying to run.
Information about the latest migration is stored in