# Zone Ingress authentication

To obtain a configuration from the control-plane, a zone ingress must authenticate itself. There are several authentication methods availble.

# Service Account Token

On Kubernetes, A zone-ingress proxy proves its identity by leveraging the ServiceAccountToken (opens new window) that is mounted in every pod.

# Zone Ingress token

On Universal, a zone-ingress proxy must be explicitly configured with a unique security token (Zone Ingress token) that will be used to prove its identity.

The data plane proxy token is a JWT token (opens new window) that contains:

  • Zone in which zone ingress operates
  • Expiration date of the token (required, 10 years if not specified)

The Zone Ingress token is signed by a signing key that is autogenerated on 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
1

which returns something like:

NAME                               AGE
zone-ingress-token-signing-key-1   7s
1
2

# Usage

Generate the token with the REST API:

curl -XPOST \
  -H "Content-Type: application/json" \
  --data '{"zone": "us-east", "validFor": "720h"}' \
  http://localhost:5681/tokens/zone-ingress
1
2
3
4

or with kumactl:

kumactl generate zone-ingress-token \
  --zone us-east \
  --valid-for 720h > /tmp/kuma-ingress-token
1
2
3

The token should be stored in a file and then passed when you start kuma-dp:

kuma-dp run \
  --proxy-type=ingress \
  --dataplane-file=ingress.yaml
  --cp-address=https://127.0.0.1:5678 \
  --dataplane-token-file=/tmp/kuma-ingress-token
1
2
3
4
5

You can also pass the token as a KUMA_DATAPLANE_RUNTIME_TOKEN environment variable.

# Token Revocation

Kuma 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 jti key. You can extract ID from token using jwt.io or jwt-cli (opens new window) tool. Here is example of jti

0e120ec9-6b42-495d-9758-07b59fe86fb9
1

Specify list of revoked IDs separated by , and store it as GlobalSecret named zone-ingress-token-revocations

    # Signing key rotation

    If the signing key is compromised, we must rotate it and all the tokens that was signed by it.

    1. Generate new signing key The signing key is stored as a GlobalSecret with a name that looks like zone-ingress-token-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 tokens Create new Zone Ingress tokens. 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.

        # Multizone

        When running in multizone, mode we can generate Zone Ingress token both on global and zone control plane. If the deployment pipeline is configured to generate data plane proxy token before running the proxy, it can rely on the Zone CP. This way Global CP is not a single point of failure.

        # None

        You can turn off authentication by setting KUMA_DP_SERVER_AUTH_TYPE to none.

        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.

        Last Updated: 4/7/2022, 3:45:22 PM