[gaborszakacs]

RDE-534

Draft until the rde-agent id-token verbs ship. The backend mint is bitrise-io/bitrise-codespaces#380, the agent install on every session is bitrise-io/bitrise-codespaces#386, and the verbs themselves are the next PR; the command names and flags on the page follow the agreed design and get a final check against the shipped --help before this merges.

TLDR

• New page: Cloud authentication with OIDC, under RDE › Configuration
• OIDC overview gains a short "Identity tokens for Remote Dev Environments" section with the session subject format
• AWS and GCP pages get a one-admonition pointer; their provider-side steps stay the single source for both CI and RDE. On the GCP page the Grant access example is corrected (the filter value is the subject string, not the literal sub) and a dropped link is restored
• New page listed in static/llms.txt

Tokens are requested on demand through rde-agent id-token

The preinstalled rde-agent command does the work: id-token get prints the token, id-token aws exchanges it with STS itself and prints credential_process output, id-token gcp wraps it for Google's executable-sourced credentials. The recipes are therefore one line in the warmup script for AWS (aws configure set credential_process ...) and a credential configuration file written to the application default credentials location for GCP, with gcloud activated in the same step. Nothing runs in the background and no identity token is kept on the machine; the SDKs cache the exchanged credential until it expires and call the command again. This is the same pull model as the git credential helper the GitHub integration uses, and it came out of the review thread on the RFC: https://bitrise.atlassian.net/wiki/spaces/ENGI/pages/5293735999

The GCP recipe is console-only and came out of a staging run: the token audience is the provider's allowed audience (not the configuration file's audience), and the service account grant has to match session identities, so the recipe maps workspace_id to a provider attribute and filters on it.

Two things on the page are deliberate and worth a glance: the GCP variables are exposed template variables rather than script exports, since exports never reach a session's terminals; and both recipes live in the warmup script, since the files they write survive restores.

The provider-side setup (IAM identity provider, trust policy, workload identity pool) is identical for builds and sessions, so it stays on the existing AWS and GCP pages rather than being duplicated.

No changelog entry yet; it gets added when this merges so the date is right.

Testing

• npm run build: passes for both locales; the only broken-anchor warnings are pre-existing ones on four /ja/ pages this PR does not touch

🤖 Generated with Claude Code

[github-actions]

Preview: https://rde-oidc.bitrise-docs.pages.dev

[zoltan-baba]

Two things in oidc-cloud-authentication.mdx that I'd double-check against bitrise-io/bitrise-codespaces#388 (the rde-agent id-token implementation):

1. "No identity token is stored on the machine" (How it works)
True for OIDC tokens: the agent mints one per call and prints it. But on every boot the agent writes the session's machine token to ~/.config/bitrise/rde-agent.env (mode 0600), so processes that don't inherit the boot environment (an SSH terminal, an IDE, an SDK's credential process) can still call rde-agent id-token. A security-minded reader may want the page to say that a session credential does live on the machine, and that it is what lets the command mint tokens.

2. "rde-agent is on the PATH of every session" (The rde-agent id-token commands)
The boot script links the binary into /usr/local/bin with sudo ln -sfn. If that fails, the boot log prints could not link rde-agent into /usr/local/bin: call it as /opt/bitrise/rde/bin/rde-agent and the session boots anyway. That's an edge case, but the page could mention the fallback path, or soften "every session".

Source: backend/internal/instancemanager/script_agent.go on feat/rde-agent-id-token.

[gaborszakacs]

Two things in oidc-cloud-authentication.mdx that I'd double-check against bitrise-io/bitrise-codespaces#388 (the rde-agent id-token implementation):

1. "No identity token is stored on the machine" (How it works) True for OIDC tokens: the agent mints one per call and prints it. But on every boot the agent writes the session's machine token to ~/.config/bitrise/rde-agent.env (mode 0600), so processes that don't inherit the boot environment (an SSH terminal, an IDE, an SDK's credential process) can still call rde-agent id-token. A security-minded reader may want the page to say that a session credential does live on the machine, and that it is what lets the command mint tokens.

2. "rde-agent is on the PATH of every session" (The rde-agent id-token commands) The boot script links the binary into /usr/local/bin with sudo ln -sfn. If that fails, the boot log prints could not link rde-agent into /usr/local/bin: call it as /opt/bitrise/rde/bin/rde-agent and the session boots anyway. That's an edge case, but the page could mention the fallback path, or soften "every session".

Source: backend/internal/instancemanager/script_agent.go on feat/rde-agent-id-token.

Good callouts:

1. It's tricky, it's technically true that no OIDC token lives on the machine but one can generate a new one with the session's "machine token". It can get confusing if we try to explain how it works, I'd simply delete these two sentences and let the security conscious customers reach out if they're interested in how it exactly works.

Nothing runs in the background, and no identity token is stored on the machine. This is the same on-demand model that the GitHub integration uses for git credentials.

2. This is true but shouldn't happen (or if it does, we should fix it rapidly), so I wouldn't confuse the reader with this scenario.