p0cli: allow: How to use the p0 allow command

Last updated: May 1, 2025

Overview

The p0 allow command lets you declare standing access grants for principals (users, service accounts, groups) across your organization’s platforms—AWS, GCP, Kubernetes, Okta, PostgreSQL, Snowflake, SSH, and Google Workspace. Instead of requesting and approving, so when user requests it is allowed automatically for the duration of the allow.

Provisions the grant in the target system
Applies your organization’s policy guardrails (auto-revoking at expiry)
Audits every grant with your reason and durations

Use p0 allow to onboard team members, set up long-lived service roles, or delegate cross-platform access with full visibility.

Prerequisites

Logged-in user

p0 login <organization-slug>

Caches your identity; p0 allow will prompt you to authenticate if needed.
Tenant config
Ensure your ~/.p0/config.json has the correct appUrl for your P0 tenant.
Network access
Allow HTTPS to https://<your-tenant>/o/<org-slug>/command/.

Syntax

p0 allow <provider> <subcommand> [resource args…]
    --to <principal>
    --length <duration>
    --requested-duration <duration>
    [--start <timestamp>]
    [--reason <text>]
    [--wait]

<provider>
One of:

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. alice@example.com)
--length <duration>
How long the standing access exists (e.g. 1 month)
--requested-duration <duration>
Maximum TTL per individual request (e.g. 4 hours)
--start <timestamp> (optional)
When the grant should begin (ISO 8601 or common date formats)
--reason <text> (optional)
Justification for audit logs
--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)
--requested-duration <dur>		string	Required. TTL for each individual session (e.g. 6 hours, 30 minutes)
--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
--wait	-w	boolean	(Optional) Block CLI until the backend confirms the grant is active
--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 alice@example.com \
  --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 bob@example.com \
  --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 two weeks, sessions lasting up to 12 hours.

3. SSH: Add to an Access Group

p0 allow ssh group --name devs \
  --to charlie@example.com \
  --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 one week, each session up to four hours.