You are browsing documentation for an older version. See the latest documentation here.
Multi-zone authentication
To add to the security of your deployments, Kong Mesh provides token generation for authenticating remote control planes to the global control plane.
The control plane token is a JWT that contains:
- The name of the zone the token is generated for
- The token’s serial number, used for token rotation
The control plane token is signed by a signing key that is autogenerated on the global control plane. The signing key is SHA256 encrypted.
You can check for the signing key:
$ kumactl get global-secrets
which returns something like:
NAME AGE
control-plane-signing-key-0001 36m
Set up tokens
To generate the tokens you need and configure your clusters:
- Generate a token for each remote control plane.
- Add the token to the configuration for each remote zone.
- Enable authentication on the global control plane.
Generate token for each remote zone
On the global control plane, authenticate and run the following command:
$ kumactl generate control-plane-token --zone=west > /tmp/token
$ cat /tmp/token
The generated token looks like:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJab25lIjoid2VzdCIsIlRva2VuU2VyaWFsTnVtYmVyIjoxfQ.kIrS5W0CPMkEVhuRXcUxk3F_uUoeI3XK1Gw-uguWMpQ
For authentication to the global control plane on Kubernetes, you can port-forward port 5681 to access the API.
Add token to each remote configuration
Enable authentication on the global control plane
If you are starting from scratch and not securing existing Kong Mesh deployment, you can do this as a first step.
Verify the remote control plane is connected with authentication by looking at the global control plane logs:
2021-02-24T14:30:38.596+0100 INFO kds.auth Remote CP successfully authenticated using Control Plane Token {"tokenSerialNumber": 1, "zone": "cluster-2"}
Rotate tokens
If a control plane token or signing key is compromised, you must rotate all tokens.
Generate new signing key
The signing key is stored as a GlobalSecret
with a name that looks like control-plane-signing-key-{serialNumber}
.
Make sure to generate the new signing key with a serial number greater than the serial number of the current signing key.
Regenerate control plane tokens
Create and add a new token for each remote control plane. These tokens are automatically created with the signing key that’s assigned the highest serial number, so they’re created with the new signing key.
Make sure the new signing key is available; otherwise old and new tokens are created with the same signing key and can both provide authentication.
Remove the old signing key
All new connections to the global control plane now require tokens signed with the new signing key.
Restart the global control plane
Restart all instances of the global control plane. All connections are now authenticated with the new tokens.
Explore an example token
You can decode the tokens to validate the signature or explore details.
For example, run:
$ kumactl generate control-plane-token --zone=west
which returns:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJab25lIjoid2VzdCIsIlRva2VuU2VyaWFsTnVtYmVyIjoxfQ.kIrS5W0CPMkEVhuRXcUxk3F_uUoeI3XK1Gw-uguWMpQ
Paste the token into the UI at jwt.io, or run
$ kumactl generate control-plane-token --zone=west | jwt
The result looks like:
Additional security
By default, a connection from the remote control plane to the global control plane is secured with TLS. You should also configure the remote control plane to verify the certificate authority (CA) of the global control plane.