Configure the Identity Service

Configure the Identity Service metadata Redis, tenant, service registration, agent-key settings, and TLS.

You configure the Identity Service with the Helm values of its own release, in values-ids.yaml. No service chart reads these values or checks them against its own, so keep the Secret names, Service addresses, and tenant consistent across releases yourself.

The Identity Service reads its configuration only when it starts. A changed value rolls the pod at helm upgrade. A changed Secret that you own doesn't roll the pod unless you also change its checksum value. See Rotate credentials.

To see every value and its default, run:

helm show values redis-ai/iris-identity-service --version 1.0.0

Metadata Redis

The metadata Redis holds the hashed agent keys, their grants, and subject grants. If you lose it, every agent loses access.

The Secret's key holds a configuration fragment:

metadata:
  urls: ["rediss://<metadata-user>:<metadata-password>@<metadata-host>:<metadata-port>"]

• The Identity Service always uses database 0. It ignores a /<db> index in the URL.
• Don't change the host after the first install. The Identity Service then reads an empty database, and every key stops working. To move the data, follow Move the metadata Redis.
• Turn on persistence (append-only file or RDB snapshots) and keep the data directory on durable storage. Without persistence, a Redis restart deletes every key.

Control token

The control token always works, also when operator sign-in is on. Give only a small group access to its Secret. For what it can do, see Credentials.

For GitOps tools such as Argo CD or Flux, supply the control token with control.existingSecret. These tools render the chart without cluster access, so a generated token changes on every render.

Tenant

Set singleTenantID to the same value as the tenantId of every service release. The Identity Service adds this tenant to each grant that names no tenant, and rejects a grant that names another tenant with 400.

A tenant ID is 1 to 256 characters, without | or control characters. Matching is exact and case-sensitive. For a numeric ID, quote it in YAML or set it with --set-string, so Helm keeps it as a string. You can't change the tenant after you mint keys: keys, grants, and service data keep the old ID.

Register services

Each service needs two entries on the Identity Service release:

• A runtime credential in runtime.serviceCredentials, so the service's data plane can check agent keys.
• A grant validator in productValidation.products.<product>, so the Identity Service can check the service's resources before it stores a grant.

This table lists the entries for each service, with the release names and Secret names used in the associated deployment guide:

The runtime credential Secret is the same Secret that the service's data plane mounts, and the internal token Secret is the same Secret that its control plane mounts. If you install a service under another release name or fullnameOverride, change the validator address to match. For the service-side values, see each service's deploy guide.

Serve several services from one release

One release serves every service. Write all entries in one values file. Helm replaces lists instead of merging them, so each helm upgrade must restate every serviceCredentials entry, not only the new one.

This example serves Agent Memory and Intent Router:

runtime:
  unscopedGrantsProduct: memory
  apiKeyTenant:
    singleTenantID: default
  serviceCredentials:
    - name: memory-dp
      subject: memory-dp
      allowedOperations: [api-key-introspect]
      allowedProducts: [memory]
      existingSecret: memory-dp-credential
      secretKey: token
    - name: intent-dp
      subject: intent-dp
      allowedOperations: [api-key-introspect]
      allowedProducts: [intent]
      existingSecret: intent-dp-credential
      secretKey: token
productValidation:
  products:
    memory:
      baseURL: http://redis-agent-memory-controlplane:9100
      credential:
        existingSecret: memory-internal-token
        secretKey: token
    intent:
      enabled: true
      baseURL: http://intent-redis-intent-router-controlplane:9400
      credential:
        existingSecret: intent-controlplane-internal
        secretKey: token

To add a service to a running release:

1. Install the service, or note its control-plane Service and Secret names.
2. Add the service's runtime credential and validator to values-ids.yaml, next to the existing entries.
3. Run helm upgrade ids redis-ai/iris-identity-service --version 1.0.0 -n <namespace-name> -f values-ids.yaml.
4. Check that GET /v1/products lists the new service.

Every service on one release uses the same tenant.

Runtime credential fields

Grant validator fields

The Identity Service calls the validator with a 5-second timeout and doesn't follow redirects. If the control plane doesn't answer, minting fails with 424.

runtime.unscopedGrantsProduct names the service that owns grants stored before grants carried a service. Set it to memory when the release serves Agent Memory. When set, it must name an enabled validator.

Agent keys and the key cache

Operator sign-in and subject grants

See Authentication and authorization for how to set them.

TLS, FIPS, and network

• Private certificate authority (CA). To reach a rediss:// metadata Redis, an https:// validator, or an IdP signed by a private CA, put the PEM bundle in a Secret and set tls.caCertSecret. The key defaults to ca.crt (tls.caCertKey). The Identity Service trusts the bundle in addition to the system CAs. The chart has no option to skip certificate verification.

  kubectl -n <namespace-name> create secret generic ids-ca --from-file=ca.crt=./ca.crt
  

• Federal Information Processing Standards (FIPS). Set security.profile: fips. The Identity Service then refuses to start unless the metadata Redis URL is rediss:// and every validator baseURL is https://.

• Network. The chart deploys no NetworkPolicy and no Ingress. Let only the service planes, your operators, and your automation reach port 9200. The health routes need no credential, so don't expose them outside the cluster.

• Another namespace. If the Identity Service runs in another namespace than a service, use fully qualified Service names, such as http://redis-agent-memory-controlplane.<product-namespace>.svc:9100, and create each shared Secret in both namespaces with the same value.

Availability and resources

Readiness checks the metadata Redis, and liveness doesn't. When the metadata Redis is unreachable, the pod turns unready and stops receiving traffic, but Kubernetes doesn't restart it. Readiness doesn't check the service control planes, so one service's outage doesn't take the Identity Service out of service.

Configuration overlays

• configData adds Identity Service settings that have no Helm value. The chart owns the credential, service, tenant, cache, and key settings, and refuses credential wiring in configData. Set operator policy either in controlAuth or in configData.auth, never both.
• Policy overlays are Secrets that hold more configuration, such as role bindings, named by secrets.secretName and secrets.additionalSecrets. Each Secret holds the overlay under the key overlay.yaml (secrets.overlayKey). The Identity Service loads them in order, after the metadata Secret. An overlay can't change the control token, the runtime credentials, or the validators. Change secrets.checksum to roll the pod after you edit an overlay Secret.

Role bindings in overlays merge by issuer, claim value, scope, and service. A later binding replaces a matching one, and a binding with role: none removes it.