> For the complete documentation index, see [llms.txt](https://docs.p0.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.p0.dev/p0-cli/p0-commands-and-usage/p0-allow.md).

# p0 allow

Declare standing pre-approved access for a principal, so future requests within the configured window are approved automatically.

### **Overview** <a href="#overview" id="overview"></a>

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. 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 to grant access to (`--to`) and the time the allow window closes (`--end`). Use `--start` to set when the window opens; it defaults to now.

***

### **Prerequisites** <a href="#prerequisites" id="prerequisites"></a>

* **Logged-in user**
* **Be an approver of the request being created**

```plaintext
p0 login <organization-slug>
```

* **Network access**

  Allow HTTPS to https\://\<your-tenant>/o/\<org-slug>/command/.

***

### **Syntax** <a href="#syntax" id="syntax"></a>

```plaintext
p0 allow <provider> <subcommand> [resource args…]
    --to <principal>
    --end <timestamp>
    [--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. <alice@example.com>)
* \--end \<timestamp>

  When the standing access expires (ISO 8601 or common date formats)
* \--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** <a href="#global-flags" id="global-flags"></a>

| **Flag**             | **Alias** | **Type** | **Description**                                                     |
| -------------------- | --------- | -------- | ------------------------------------------------------------------- |
| --to \<principal>    |           | string   | **Required.** Principal to grant (user, service account, or group)  |
| --end \<timestamp>   |           | string   | **Required.** Time the standing grant expires (e.g. 05/30/2025)     |
| --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                        |

**Timestamps** accept ISO 8601 and common date formats:

2025-05-01T09:00:00Z, 06/01/2025

***

### **Supported Providers** <a href="#supported-providers" id="supported-providers"></a>

* **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 any provider. For example:

```plaintext
p0 allow aws --help
p0 allow gcloud --help
```

***

### **Examples** <a href="#examples" id="examples"></a>

#### **1. AWS: Grant IAM Policy on a Resource** <a href="#id-1-aws-grant-iam-policy-on-a-resource" id="id-1-aws-grant-iam-policy-on-a-resource"></a>

```plaintext
p0 allow aws resource 'arn:aws:s3:::my-bucket/*' ReadOnlyAccess \
  --account 123456789012 \
  --to alice@example.com \
  --start 04/30/2025 \
  --end 05/30/2025
```

* **Subcommand:** resource \<ARN> \<policy…>
* **Account:** AWS account ID
* **Outcome:** Alice gets Read-Only access to all objects in my-bucket for one month.

***

#### **2. GCP: Grant an IAM Role** <a href="#id-2-gcp-grant-an-iam-role" id="id-2-gcp-grant-an-iam-role"></a>

```plaintext
p0 allow gcloud role roles/viewer \
  --project my-gcp-project \
  --to bob@example.com \
  --start 04/30/2025 \
  --end 05/14/2025
```

* **Subcommand:** role \<role-name>
* **Project:** GCP project ID
* **Outcome:** Bob receives the viewer role on my-gcp-project for 2 weeks.

***

#### **3. SSH: Add to an Access Group** <a href="#id-3-ssh-add-to-an-access-group" id="id-3-ssh-add-to-an-access-group"></a>

```plaintext
p0 allow ssh group --name devs \
  --to charlie@example.com \
  --start 04/30/2025 \
  --end 05/07/2025
```

* **Subcommand:** group --name \<group-name>
* **Outcome:** Charlie is added to the SSH access group devs for 1 week.

***

### **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](/access-management/access-management/just-in-time-access/approving-access/p0-allow-workflows.md) 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 [Access Management](/access-management/access-management.md) **→ Pre Approvals** to view and revoke allows. Creating or editing one is done from the Slack modal or the CLI, above.

***

### **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 policies, configured in [Policy Studio](/policy-studio/policy-studio.md). 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 access policy 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` or `--end`, 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](/p0-cli/troubleshooting/p0-allow.md) for detailed tables covering authentication failures, network issues, flag validation, backend errors, and retry guidance.