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 with p0 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 delete identity.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 rerun p0 logout if refreshes stall.
Network issues: fetch failed or Unable to reach the server indicates an egress, DNS, or TLS problem—verify connectivity to https://<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-run p0 allow <provider> --help to confirm arguments.
Rate limits and backend errors: 429 and 500 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.

Previousp0 ls Nextp0 grant

Last updated 6 days ago