# 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. 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**
```plaintext
p0 login
```
* **Network access**
Allow HTTPS to https\://\/o/\/command/.
***
### **Syntax**
```plaintext
p0 allow [resource args…]
--to
--length
[--start ]
[--reason ]
[--wait]
```
* \
* `aws`
* `azure-ad`
* `gcloud`
* `k8s`
* `okta`
* `pg`
* `snowflake`
* `ssh`
* `workspace`
* \ & resource args
Provider-specific (see Examples below or run p0 allow \ --help)
* \--to \
Email or identifier (e.g. )
* \--length \
How long the standing access exists (e.g. 1 month)
* \--start \ *(optional)*
When the grant should begin (ISO 8601 or common date formats)
* \--reason \ *(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 \ | | string | **Required.** Principal to grant (user, service account, or group) |
| --length \ | | string | **Required.** Total duration of the standing grant (e.g. 2 weeks, 5 days) |
| --start \ | | string | (Optional) Grant start time (e.g. 2025-05-01T09:00:00Z, 06/01/2025) |
| --reason \ | | 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:
```plaintext
p0 allow aws --help
p0 allow gcloud --help
# …etc.
```
***
### **Examples**
#### **1. AWS: Grant IAM Policy on a Resource**
```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 \ \
* **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**
```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 \
* **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**
```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 \
* **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](/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 ` 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 ` 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 [access policies](/access-management/just-in-time-access/request-routing.md); otherwise creation is blocked.
* Ensure outbound HTTPS to `https:///o//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:///o//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 --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](/p0-cli/troubleshooting/p0-allow.md) for detailed tables covering authentication failures, network issues, flag validation, backend errors, and retry guidance.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.p0.dev/p0-cli/p0-commands-and-usage/p0-allow.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.