Authentication and authorization

Understand the Intent Router credentials, agent-key grants, and how to load the administration tokens.

Self-managed Intent Router uses two kinds of credentials. Service tokens authenticate operators and the Intent Router components to each other. The chart generates the control-plane tokens for you by default. Agent keys authenticate applications to the data plane, and each key's grants control which Routers it can use and what it can do on them.

This page lists each credential and what it unlocks. It also shows how to load the administration tokens and how grants authorize agent keys. It then covers connecting an Identity Service deployed outside this chart and rotating credentials.

Credentials

controlplane.adminToken and controlplane.internalToken default to autoGenerate: true: without existingSecret, the chart creates a random Secret named <release>-redis-intent-router-controlplane-admin-token or -internal-token, with the key token, keeps it across upgrades, and never rotates it. For a release named intent, the admin token is in intent-redis-intent-router-controlplane-admin-token. The chart never generates identityService.credential. Set existingSecret to supply your own, and set the matching existingSecretChecksum so the pods roll when the Secret changes. Two credentials can't reference the same Secret key, and rendering fails if they do.

An agent key gets 401 from the control plane. A key without a grant on a Router, or without the action an operation needs, gets 403 from the data plane. The data plane holds no credential for the control plane: the planes never call each other.

Load the administration tokens

Every Router operation needs the admin token in Authorization: Bearer <token>, and every agent-key operation needs the Identity Service control token. The health routes need no credential.

Load both from their Secrets before you call the control plane or the Identity Service. The admin token uses the Secret name from Deploy. The control token example assumes an Identity Service release named ids that generates its control token; with control.existingSecret, read that Secret instead:

export IRIS_INTENT_ROUTER_SERVICE_TOKEN="$(kubectl -n <namespace-name> get secret \
  intent-controlplane-admin -o jsonpath='{.data.token}' | base64 --decode)"
export IRIS_IDENTITY_TOKEN="$(kubectl -n <namespace-name> get secret \
  ids-iris-identity-service-control-token -o jsonpath='{.data.token}' | base64 --decode)"

Router authorization and grants

An agent key needs a grant on each Router it uses:

A grant can't use a wildcard resource ID and can't carry constraints. The Identity Service mints a key only for a Router that exists in the tenant. It asks the control plane to confirm this through the grant-validation callback, authenticated with the internal token.

The data plane checks every key with the Identity Service, which caches the answer. A revoked key stops working within the Identity Service's cache lifetime, runtime.cache.hardTtlSeconds on the Identity Service release, 300 seconds by default. The API examples show the complete request.

Configure the Identity Service

The Intent Router chart deploys no Identity Service. Install the Identity Service as its own release, point dataplane.identityServiceBaseURL at it, and set identityService.credential.existingSecret to the runtime credential it accepts. For an http:// in-cluster URL, also set identityService.allowInsecureTransport=true; the FIPS profile refuses it. Then set these values in the Identity Service release, so it checks grants and accepts the data plane's runtime credential:

Rotate credentials

To rotate a token, update its Secret and its existingSecretChecksum and run helm upgrade, so the pods roll. Rotate the internal token on the Identity Service release at the same time, because the two must match. Rotate an agent key with the Identity Service, as shown in Rotate or revoke agent keys.