Namespace
Instances and runners authenticate as the workspace they belong to.
Instances and runners authenticate as the workspace they belong to.
Identity proof
The token has to come from https://federation.namespaceapis.com, and its tenant_id claim has to match the workload you named. We compare that claim byte for byte, with no wildcards.
tenant_id is matched rather than sub, which on this platform does not name the workload in a form you can pin.
Every token also has to name your workspace as its audience. Ask for this audience and no other. A token requested for two audiences fails every exchange.
Console fields
| Field | Example | Advanced | What it pins |
|---|---|---|---|
| Workspace ID | tenant_123456789ab | no | Dashboard → Workspace settings. Every instance and member of the workspace matches. |
The console also asks which project and environment this identity reaches and which role it gets, with the credential lifetime behind Advanced.
Trust
Built from the example answers above:
| What | Value |
|---|---|
| Issuer | https://federation.namespaceapis.com |
| Claim compared | tenant_id |
| Subject | tenant_123456789ab |
| Identity name | namespace-tenant-123456789ab |
We name the identity for you, so the form never asks for one.
Console snippet
T=$(nsc auth issue-id-token --audience YOUR_WORKSPACE_ID)
C=$(curl -sS "https://penv.cloud/api/v1/auth/oidc" \
-H 'content-type: application/json' \
-d "{\"token\":\"$T\"}" | jq -r .credential)
PENV_TOKEN="$C" penv pullThe snippet finishes with penv pull, which writes a file. We recommend penv run for a process; penv pull is for a host that needs a file on disk. Connect your CI has the wrapped step.
Related
- Machine identity
- Connect a Platform in the console
- Namespace documentation: the subject is the value most often set wrong