# p0 allow

### **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 being granted (`--to`), how long the allow window remains active (`--length`), and the maximum duration for each auto-approved request (`--requested-duration`).

***

### **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>
    --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. <alice@example.com>)
* \--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** <a href="#global-flags" id="global-flags"></a>

| **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** <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 the provider:

```plaintext
p0 allow aws --help
p0 allow gcloud --help
# …etc.
```

***

### **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 \
  --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** <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 \
  --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** <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 \
  --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](https://docs.p0.dev/orchestration/just-in-time-access/approving-access/p0-allow-workflows) 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](https://docs.p0.dev/orchestration/just-in-time-access/request-routing); 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](https://docs.p0.dev/p0-cli/troubleshooting/p0-allow) for detailed tables covering authentication failures, network issues, flag validation, backend errors, and retry guidance.