opschain admin transport-grants create

packs:rpc

Proposes a transport grant. On a composition carrying the approval fabric the grant lands pending and opens its funnel checklist — --approvers is required, a governed grant is never approver-less — and is then approved through the approvals inbox. Without the fabric the grant activates directly (the base posture).

A literal --provider must name a registered transport provider's code; a glob (nonprod-*) is accepted unchecked, covering providers yet to be registered. Requires the packs:rpc entitlement and a stepped-up session (when step-up is composed).

A user subject is stored and matched as the principal id, never the username. --subject (and each --approvers entry) takes a principal id, a username exactly one account holds, or <provider>:<username> — the account's auth_provider value as opschain admin users list shows it (local:sam, ldap:corp:sam, oidc:okta:sam). A bare username two accounts hold is refused by name with that remedy, so a federated sam never inherits local sam's grant.

opschain admin transport-grants create \
  --subject-kind user --subject sam \
  --provider prod-ssh \
  --scope '/projects/limebank/environments/prod/**' \
  --actions exec,put --require-step-up \
  --approvers priya --note "prod incident access"
Created transport grant 019a… (pending) for user:sam on provider prod-ssh
The grant is held by the approvals funnel - approve it with: opschain approvals approve 019a…

Flags

Flag	Meaning
--subject-kind <kind>	Who the grant admits: user, group, service_account or agent_group.
--subject <identity>	The subject's identity: for a user its principal id, username or <provider>:<username> (stored as the principal id); else a group name, service-account id, or agent fleet-group name.
--provider <code-or-glob>	The granted transport provider's code, or a code glob.
--scope <node-path-glob>	The node-path glob sessions may target, e.g. /projects/*/environments/nonprod/**.
--actions <patterns>	rpc action patterns (comma-separated); omit for every action.
--require-step-up	Demand a stepped-up session from the requesting principal at session minting.
--rate-per-minute <n>	Cap: sessions per minute (0 = capless). Refusals land warn:transport:cap_refused.
--sessions-per-day <n>	Cap: sessions per UTC day (0 = capless).
--approvers <users>	The funnel checklist's approvers as principal ids, usernames or <provider>:<username> (required when the approval fabric is composed; stored as principal ids).
--note <text>	Why the grant exists.
--expires-in <duration>	Validity window from now (e.g. 720h); omit to grant until revoked.
--server <url>	Server base URL (default: the active context / OPSCHAIN_SERVER).
--auth-token <token>	Admin bearer token override (default: your opschain login session, then $OPSCHAIN_ADMIN_TOKEN, then the token stored by opschain admin login).

See also

• opschain docs cli/approvals-approve — releasing a held grant through the funnel.
• opschain docs cli/admin-identity-convert-username-subjects — rewriting grants written with a username subject.