p0 allow
Overview
The p0 allow command lets you declare pre-approved access for principals (users, service accounts, groups) across your organization’s platforms AWS, GCP, Kubernetes, Okta, PostgreSQL, Snowflake, SSH, and Google Workspace so that when a user requests access, it’s automatically granted for the specified duration without manual approval.
Use p0 allow to onboard team members, set up long-lived service roles, or delegate cross-platform access with full visibility. At the time of pre-approval, the command records who can be auto-approved, the relevant resource, and how long both the standing grant and individual sessions last.
At minimum you must provide the identity being granted (--to
), how long the allow window remains active (--length
), and the maximum duration for each auto-approved request (--requested-duration
).
Prerequisites
Logged-in user
Be an approver of the request being created
p0 login <organization-slug>
Network access
Allow HTTPS to https://<your-tenant>/o/<org-slug>/command/.
Syntax
p0 allow <provider> <subcommand> [resource args…]
--to <principal>
--length <duration>
[--start <timestamp>]
[--reason <text>]
[--wait]
<provider>
aws
azure-ad
gcloud
k8s
okta
pg
snowflake
ssh
workspace
<subcommand> & resource args
Provider-specific (see Examples below or run p0 allow <provider> --help)
--to <principal>
Email or identifier (e.g. [email protected])
--length <duration>
How long the standing access exists (e.g. 1 month)
--start <timestamp> (optional)
When the grant should begin (ISO 8601 or common date formats)
--reason <text> (optional)
Justification for audit logs and provide the approver with justification for request.
--wait / -w (optional)
Block until provisioning completes
Global Flags
Flag
Alias
Type
Description
--to <principal>
string
Required. Principal to grant (user, service account, or group)
--length <duration>
string
Required. Total duration of the standing grant (e.g. 2 weeks, 5 days)
--start <timestamp>
string
(Optional) Grant start time (e.g. 2025-05-01T09:00:00Z, 06/01/2025)
--reason <text>
string
(Optional) Why this access is needed
--help
boolean
Show provider-specific usage and subcommands
Durations accept human-friendly strings:
10 minutes, 2 hours, 5 days, 1 week, 1 month
Supported Providers
AWS (p0 allow aws …)
Azure AD (p0 allow azure-ad …)
GCP (p0 allow gcloud …)
Kubernetes (p0 allow k8s …)
Okta (p0 allow okta …)
PostgreSQL (p0 allow pg …)
Snowflake (p0 allow snowflake …)
SSH (p0 allow ssh …)
Workspace (p0 allow workspace …)
For the full list of subcommands and resource arguments, append --help after the provider:
p0 allow aws --help
p0 allow gcloud --help
# …etc.
Examples
1. AWS: Grant IAM Policy on a Resource
p0 allow aws resource arn:aws:s3:::my-bucket/* ReadOnlyAccess \
--account 123456789012 \
--to [email protected] \
--start 04/30/2025 \
--length '1 month' \
--requested-duration '1 days'
Subcommand: resource <ARN> <policy…>
Account: AWS account ID
Outcome: Alice gets Read-Only access to all objects in my-bucket for one month, each session up to one day.
2. GCP: Grant an IAM Role
p0 allow gcloud role roles/viewer \
--project my-gcp-project \
--to [email protected] \
--start 04/30/2025 \
--length '2 weeks' \
--requested-duration '12 hours'
Subcommand: role <role-name>
Project: GCP project ID
Outcome: Bob receives the viewer role on my-gcp-project for 2 weeks, sessions lasting up to 12 hours.
3. SSH: Add to an Access Group
p0 allow ssh group --name devs \
--to [email protected] \
--start 04/30/2025 \
--length '1 week' \
--requested-duration '4 hours'
Subcommand: group --name <group-name>
Outcome: Charlie is added to the SSH access group devs for 1 week, each session up to 4 hours.
Using P0 Allow Across Interfaces
P0 allow can be configured from the Slack modal, the CLI, or the P0 web UI. Each surface writes to the same standing-access record, so changes made in one place reflect everywhere else. See P0 Allow Modal, CLI, and UI for screenshots and walkthroughs.
Slack modal: Launch
/p0 allow
to open an interactive form with provider drop-downs plus date/time and duration pickers. Submit to create, or revisit via/p0 allow list
to edit and revoke — the modal replays backend validation errors inline if something is misconfigured.CLI:
p0 allow <provider> <subcommand>
gives full flag control for automation, templating, or CI jobs. Use provider--help
flags and combine withp0 ls
for resource discovery.P0 App UI: Navigate to Just-in-time → Standing access to add, edit, or revoke allows with filters, CSV export, and status tracking. The UI surfaces the same backend validation messages you would see from the modal or CLI.
Authentication & Security Requirements
Log in with
p0 login <organization-slug>
before issuing an allow. The CLI uses Authorization Code + PKCE and persists a bearer token in~/.p0
.The backend requires that bearer token on every call; client credentials, device, or refresh-token-only flows are not supported. If the token cache becomes corrupt, run
p0 logout
(or deleteidentity.json
) and authenticate again.You must already be an approver for the target resource under your organization’s routing rules; otherwise creation is blocked.
Ensure outbound HTTPS to
https://<tenant>/o/<org-slug>/command/
so the CLI, modal, and UI can reach the API.Optional routing rule settings like
requireReason: true
force justification text in every interface.
Limits & Version Notes
The CLI, modal, and UI share the same backend. There are no published client-version requirements or per-interface quotas today. Use provider --help
commands for arguments that may evolve by integration.
Common Errors & Recovery
Here are the most common scenarios you encounter:
Authentication failures: The CLI prompts for
p0 login
when OIDC tokens are missing or stale. Clear~/.p0/cache
or rerunp0 logout
if refreshes stall.Network issues:
fetch failed
orUnable to reach the server
indicates an egress, DNS, or TLS problem—verify connectivity tohttps://<tenant>/o/<org>/command/
and ensure the system clock is accurate.Flag validation: Missing
--to
,--length
, or--requested-duration
, bad timestamps, or unknown flags trigger inline errors in every interface. Re-runp0 allow <provider> --help
to confirm arguments.Rate limits and backend errors:
429
and500
responses should be retried with backoff; escalate persistent 500s with timestamps to P0 support.
Refer to p0 allow troubleshooting for detailed tables covering authentication failures, network issues, flag validation, backend errors, and retry guidance.
Last updated