Repository navigation
Conversation
…e chart Restructure the Identity Service section like the other Iris services (overview + self-managed/ subsection) and rewrite it from the on-prem operator guide for redis-iris 1.0. Old URLs keep aliases. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
🧠 Redis MemoryFound 6 related items from repository history:
Memory updated at 5182f7b |
Contributor
…hart Subject grants have no effect under redis-iris, so signed-in MCP users get access through gateway_user. Identity Service OIDC is set with global.iris.auth. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
nkanu17
reviewed
Nov 4, 2026
nkanu17
left a comment
nkanu17
left a comment
Contributor
There was a problem hiding this comment.
Nice, this is right. I traced it through iris d027b6ed1 (main hasn't touched these files since): in the redis-iris chart nothing can read subject grants, so signed-in users get in through gateway_user, and agent keys are how you scope an agent to specific Gateways. Nothing blocking. I left a few small wording suggestions inline.
A few things outside the diff:
deploy.md:33still says "see the Identity Service guide" for every IdS setting, but this PR takes those values out of that guide, so the link doesn't help anymore.- The Agent Memory pages (
self-managed/prerequisites.md:291,configuration.md:33) still describe a separatevalues-ids.yamlwithsubjectGrants. Fine to leave for a follow-up, but they'll need the same treatment. - In the PR description, it's worth saying the role fallback also kicks in when IdS is down, not just when the lookup is refused.
And some things I ran into in the code that aren't for this PR, just so they're written down:
- On a healthy suite install, every signed-in request does the subject-grant lookup, gets a 403 back, and logs a "failing closed" warning plus bumps the failure metrics, even though the user gets in fine. Operators are going to see that and worry. We should skip the lookup when the credential can't do it, or treat that 403 as "no grants".
- Because of the same fallback, if IdS goes down,
gateway_userusers keep working while agent keys fail. Might be what we want, but we should decide and then document it. - A signed-in user without the role probably gets a 503 "retry" instead of a 403. I only traced this in code, haven't seen it on a real install.
- The auth-docs ticket (MOD-20066) has a row saying the CG credential "also needs
subject-grant-lookup". That's only true for the standalone chart, so it should be scoped or dropped, otherwise someone will "fix" these docs back.
| | Identity Service control token | Operator → Identity Service (`:9200`) | Set on the Identity Service release. By default the Identity Service chart generates it (`control.autoGenerate: true`), so read it from the Secret the chart generates | Yes, by default | Creating, listing, rotating, and revoking agent keys | | ||
| | Agent key | Agent → Data Plane (`:8083`) | None. Returned once when minted or rotated | No | Listing and calling tools on the Gateways its grants name | | ||
| | Identity provider access token | Agent → Data Plane (`:8083`) | None. Issued by your identity provider | No | The Gateways its role or subject grants name | | ||
| | Identity provider access token | Agent → Data Plane (`:8083`) | None. Issued by your identity provider | No | Every Gateway in the tenant, with the `gateway_user` role | |
Contributor
There was a problem hiding this comment.
Small one: this row only covers people who have the role now. Worth adding what happens without it, since they get no Gateway at all.
Suggested change
| | Identity provider access token | Agent → Data Plane (`:8083`) | None. Issued by your identity provider | No | Every Gateway in the tenant, with the `gateway_user` role | | |
| | Identity provider access token | Agent → Data Plane (`:8083`) | None. Issued by your identity provider | No | With the `gateway_user` role, every Gateway in the tenant. Without it, none | |
| - Assign Identity Service subject grants to individual users for selected Gateways, with `POST /v1/subject-grants/apply` on the Identity Service. See [subject grants](/content/operate/iris/identity-service/authentication.md#subject-grants) for the request. A subject grant names the IdP's issuer, the user's `user_id_claim` value, and the same product, resource type, Gateway ID, and `use` action as an agent-key grant. | ||
|
|
||
| A specific subject grant cannot narrow the all-Gateway role, and removing a subject grant does not remove access that a role gives. To restrict a user to selected Gateways, don't map them to `gateway_user`. | ||
| Signed-in users can't be limited to selected Gateways: Identity Service [subject grants](/content/operate/iris/identity-service/self-managed/authentication.md#subject-grants) have no effect in a `redis-iris` installation. To give an agent access to selected Gateways only, give it an agent key with a grant for each one. |
Contributor
There was a problem hiding this comment.
This reads fine, but anyone coming from the old page was told "don't map them to gateway_user, use subject grants instead". Now leaving them out of the role means they get nothing, so I'd spell that out, and say why.
Suggested change
| Signed-in users can't be limited to selected Gateways: Identity Service [subject grants](/content/operate/iris/identity-service/self-managed/authentication.md#subject-grants) have no effect in a `redis-iris` installation. To give an agent access to selected Gateways only, give it an agent key with a grant for each one. | |
| In a `redis-iris` installation the Data Plane can't read Identity Service [subject grants](/content/operate/iris/identity-service/self-managed/authentication.md#subject-grants), so they have no effect. Signed-in users can't be limited to selected Gateways, and a signed-in user without `gateway_user` can't use any Gateway. To give an agent access to selected Gateways only, give it an agent key with a grant for each one. |
| | Identity Service value | Setting | | ||
| | --- | --- | | ||
| | `runtime.serviceCredentials[]` | A credential for the Data Plane, `name: context-gateway-dp` and `subject: context-gateway-dataplane`, with `allowedOperations: [api-key-introspect]` and `allowedProducts: [context-gateway]`, from the same Secret as `dataplane.runtimeToken`. With Data Plane sign-in on, add `subject-grant-lookup` to `allowedOperations`. | | ||
| | `runtime.serviceCredentials[]` | A credential for the Data Plane, `name: context-gateway-dp` and `subject: context-gateway-dataplane`, with `allowedOperations: [api-key-introspect]` and `allowedProducts: [context-gateway]`, from the same Secret as `dataplane.runtimeToken`. | |
Contributor
There was a problem hiding this comment.
Dropping subject-grant-lookup is right. This row is standalone-only though, so I'd mention that the suite sets this credential itself and fails the render if you try to set it.
Suggested change
| | `runtime.serviceCredentials[]` | A credential for the Data Plane, `name: context-gateway-dp` and `subject: context-gateway-dataplane`, with `allowedOperations: [api-key-introspect]` and `allowedProducts: [context-gateway]`, from the same Secret as `dataplane.runtimeToken`. | | |
| | `runtime.serviceCredentials[]` | A credential for the Data Plane, `name: context-gateway-dp` and `subject: context-gateway-dataplane`, with `allowedOperations: [api-key-introspect]` and `allowedProducts: [context-gateway]`, from the same Secret as `dataplane.runtimeToken`. The `redis-iris` suite sets this credential and fails the render if you set it. | |
|
|
||
| ### Subject grants | ||
|
|
||
| The control API also has routes for subject grants, `/v1/subject-grants`. In a `redis-iris` installation, no data plane reads subject grants, so they have no effect. IdP users get access from their roles in each service, and agents use agent keys. |
Contributor
There was a problem hiding this comment.
True as written, but if someone actually calls /v1/subject-grants/apply they'll get an error, not a quiet no-op, since the chart allows no grant shapes by default. Saying both halves makes that error less confusing.
Suggested change
| The control API also has routes for subject grants, `/v1/subject-grants`. In a `redis-iris` installation, no data plane reads subject grants, so they have no effect. IdP users get access from their roles in each service, and agents use agent keys. | |
| The control API also has routes for subject grants, `/v1/subject-grants`. They have no effect in a `redis-iris` installation. By default the chart allows no subject-grant shape, so the Identity Service refuses new subject grants. The chart also gives no data plane the `subject-grant-lookup` operation, so no data plane reads them. IdP users get access from their roles in each service, and agents use agent keys. |
…tity Service values Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR updates the public Identity Service docs to match the on-prem operator guide in redislabsdev/iris (
docs/iris-onprem-identity-service-operator-guide.md,mainas of 2026-11-04). The guide now targets theredis-iris1.0 suite chart.Source of truth: the
redis-iris1.0 suite chart and Teodor's guide. Where older published pages disagree, this PR follows the newer content and updates the older pages to match.Release timing: this PR doesn't depend on the 1.0.0 chart release. The suite pages already describe the 1.0 install. Release-specific operations (upgrade, rollback, recovery, uninstall) are in #4470, which stays in draft until 1.0.0 is cut.
Structure
The section now has the same layout as the other Iris services:
identity-service/_index.md: a short overview with Redis Cloud and self-managed options, like Lens.identity-service/self-managed/:_indexprerequisites(new)configurationdeployauthenticationoperationsmulti-tenant(new, preview)The four existing pages moved under
self-managed/. Each has an alias for its old URL. Inbound links from the suite page, Agent Playbooks, and Context Gateway now point to the new paths.Content changes
irisand Serviceiris-identity-service;global.iris.authinstead ofcontrolAuth;values-ids.yaml,runtime.serviceCredentials,productValidation, and workload identity. The standalone chart isn't a supported install path any more.Where older pages changed to match
redis-iris. The suite gives the Context Gateway data-plane credential onlyapi-key-introspect, so signed-in users get access throughgateway_user. To limit access to selected Gateways, use an agent key.maxResults/nextToken, CLI--limit/--cursor/--all)fips, as the suite page already sayscontrolAuth.oidcon the Identity Service releaseglobal.iris.authContext Gateway edits:
context-gateway/self-managed/authentication.md: the credentials table row and "Grant signed-in users access".context-gateway/self-managed/deploy.md: dropped "addsubject-grant-lookup".Nitin confirmed the Context Gateway subject-grant change against iris
d027b6ed1. The suite wires onlyapi-key-introspect(identity-service/helm/templates/_helpers.tpl:134), and the suite render test asserts thatsubject-grant-lookupis absent. CG falls back to roles both when IdS refuses the lookup and when IdS is down (common/infrastructure/identity/subject_access_resolver.go). So while IdS is down,gateway_userusers keep working but agent keys fail.Follow-ups outside this PR:
self-managed/prerequisites.md,configuration.md) still describe a separatevalues-ids.yamlwithsubjectGrants.subject-grant-lookup". That's standalone-only, so it should be scoped or dropped.🤖 Generated with Claude Code
Note
Low Risk
Documentation-only changes with no runtime or configuration code paths affected.
Overview
Reframes Identity Service docs around the supported
redis-iris1.0 install: a short top-level overview, a newidentity-service/self-managed/tree (prerequisites, configuration, deploy, authentication, operations, plus a multi-tenant Agent Memory preview), and aliases so old URLs still work. The former standalone-chart pages are removed; content now usesidentityService:/global.iris(includingglobal.iris.authfor operator OIDC), chart-derived service registration, generated vs GitOps credentials, tenant lifecycle, console API Keys, and updated limits (no FIPS on the suite, non-paginated key list, subject grants ineffective in suite installs).Agent Playbooks and Context Gateway pages are aligned: Identity Service operator sign-in points at the new auth guide; Context Gateway documents IdP access via
gateway_useronly (not subject grants), dropssubject-grant-lookupfrom suite deploy steps, and the suite install link forids-metadatais updated.Reviewed by Cursor Bugbot for commit 5182f7b. Bugbot is set up for automated code reviews on this repo. Configure here.