Ctrlk
Sign up for FreeKnowledge Base
For the complete documentation index, see llms.txt. This page is also available as Markdown.

🛡️Configure your first access policy

Create an access policy in P0 Security's Policy Studio to control who can request access, what they can access, and who approves. A step-by-step tutorial for security administrators.

By default, P0 routes all access requests to your Security Reviewers. As your team grows, you need more control: route requests to the right approver, restrict access to sensitive resources, or allow automatic approvals for low-risk environments.

Access policies let you define these rules. In this tutorial, you create your first access policy that routes requests from your engineering team to a specific approver group.

What you'll learn

After completing this tutorial, you are able to:

  • Navigate to Policy Studio and edit your policy configuration

  • Write a policy rule with requestor, resource, and approval sections

  • Test your policy with a real access request

  • Understand how P0 evaluates multiple policy rules

This tutorial takes about 10 minutes.

Before you start

Ensure you have the following:

  • A P0 account with Owner permissions

  • At least one resource integration installed (such as AWS, Google Cloud, or Kubernetes)

  • A Slack notifier connected to receive approval notifications

  • A directory integration installed (Google Workspace, Okta, or Microsoft Entra ID) with at least one group that contains your team members

If you haven't set up P0 yet, complete the Getting started with just-in-time access tutorial first.

Step 1: Open Policy Studio

  1. Sign in to p0.app.

  2. Navigate to Policy Studio in the left sidebar, or go to https://p0.app/o/<your-organization>/policies.

Policy Studio opens on the Control table view, which lists your existing policy rules. To edit the raw configuration, select the View options (⋯) button in the page header, then select YAML view. If this is your first time here, the list may be empty.

A policy configuration is a collection of one or more policy rules. You have one active policy configuration at any time, but it can contain as many individual rules as you need.

Step 2: Understand the policy structure

Every policy rule has three parts:

Part
Purpose
Example

Requestor

Who is making the request

The engineering team

Resource

What they are requesting access to

An AWS integration

Approval

Who can approve the request

The SRE team

Here is a minimal policy rule:

This rule means: when anyone in the Engineering group requests access to any resource, route the approval to the SRE Team group.

Step 3: Create your first policy

In the YAML view, replace the editor content with the following configuration, substituting your own values:

Replace the placeholder values:

Placeholder
What to enter

<your-team-group-id>

The group identifier for the requestors. For Google Workspace, use the group email (such as engineering@yourcompany.com). For Okta, use the group ID from the Okta admin console. For Entra ID, use the group UUID.

<Your Team Name>

A human-readable name for the requestor group (such as Engineering)

<your-approver-group-id>

The group identifier for the approvers, in the same format as above

<Approver Team Name>

A human-readable name for the approver group (such as SRE Team)

Set the directory value based on your identity provider: workspace for Google Workspace, okta for Okta, or azure-ad for Microsoft Entra ID.

The allowOneParty: false option prevents requestors from approving their own requests. Set this to true to allow self-approval.

Click Submit to activate your policy configuration.

Step 4: Test your policy

Verify that your policy works by submitting a test access request.

  1. Open Slack and navigate to the p0-requests channel.

  2. Enter /p0 request and fill in the request details for a resource covered by your policy.

  3. Confirm that the approval notification goes to a member of your approver group, not the default Security Reviewers.

  1. Navigate to Access Management and click the Request Access button.

  2. Fill in the request details for a resource covered by your policy.

  3. Confirm that the approval notification goes to a member of your approver group, not the default Security Reviewers.

If no policy rule matches a request, P0 blocks the request with the message: "This resource doesn't exist, or your organization doesn't allow this principal to access this resource." Ensure your policy configuration covers all requestors who need access.

Step 5: Add a rule for a specific service

Now extend your configuration by adding a second rule that restricts a specific service to a dedicated approver. Add the following rule after your first one:

This rule routes AWS-specific requests to a dedicated approver group and requires the requestor to provide a reason. Your first rule still handles requests for all other services.

Click Submit to activate the updated configuration.

When multiple rules match a request, P0 combines the approvers. Approval from any one matched approver is sufficient to grant access. See how P0 evaluates access policies for the full evaluation logic.

Summary

You created an access policy configuration in Policy Studio that:

  • Routes your team's access requests to a specific approver group

  • Adds a service-specific rule for AWS with a required reason

  • Replaces the default Security Reviewer approval flow with targeted approver assignment

What's next

Now that you have a working policy, you can:

PreviousGetting started with just-in-time access
NextGetting started with posture

Last updated