You are browsing documentation for an outdated version.
See the latest documentation here.
Configure zone proxy authentication
To obtain a configuration from the control plane, a zone proxy (zone ingress / zone egress) must
There are several authentication methods available.
Service Account Token
On Kubernetes, A zone proxy proves its identity by leveraging
that is mounted in every pod.
On Universal, a zone proxy proxy must be explicitly configured with a unique
security token (Zone token) with appropriate scope (
ingress), that will be used
to prove its identity.
The zone token used to identify zone proxies is a JWT token
- Zone in which zone proxy operates
- Expiration date of the token (required, 10 years if not specified)
- Scope as a list of items where the token will be valid (required,
if not specified)
The zone token is signed by a signing key that is autogenerated during the first
start of the control plane.
Tokens are never stored in the control plane, the only thing that is stored are
signing keys that are used to verify if a token is valid.
The signing key is RSA256 encrypted.
You can check for the signing key:
kumactl get global-secrets
which returns something like:
The token should be stored in a file and then passed when you start
kuma-dp run \
--proxy-type=ingress # or egress \
You can also pass the token as a
Kong Mesh does not keep the list of issued tokens. Whenever the single token is
compromised, we can add it to revocation list, so it’s no longer valid.
Every token has its own ID which is available in payload under
You can extract ID from token using jwt.io or
Here is example of
Specify list of revoked IDs separated by
, and store it as
Signing key rotation
If the signing key is compromised, we must rotate it and all the tokens that were
signed by it.
Generate new signing key
The signing key is stored as a
GlobalSecret with a name that looks like
Make sure to generate the new signing key with a serial number greater than
the serial number of the current signing key.
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.
At this point, tokens signed by either new or old signing key are valid.
Remove the old signing key
All new connections to the control plane now require tokens signed with
the new signing key.
When running in multi-zone mode, we can generate zone tokens only on the global
control plane. The zone control plane only has a public key of a signing key to verify tokens.
You can turn off authentication by setting
You should not disable authentication between the control plane and
the data plane proxies in production. Disabling means that any data plane proxy
can impersonate any service.
Legacy Zone Ingress Token
Authenticating Zone Ingress using separate Zone Ingress Token is still possible, but it is deprecated and will be removed in the future.