🔀Manage P0 policies and settings as code

Use the P0 Terraform provider to manage access policies, RBAC role assignments, and just-in-time access settings as code, with worked examples and migration guidance.

This guide shows you how to manage P0's access policies, role assignments, and just-in-time (JIT) access settings with the P0 Terraform provider. You manage the same policies and settings you would configure in the P0 dashboard. These include who can request access to what, who holds each P0 role, and the durations requestors can choose. You manage them as version-controlled, reviewable configuration.

If you haven't configured the provider yet, start with Get started with the P0 Terraform provider, which covers authentication and installing your first integration. This guide picks up from a configured provider and focuses on policies and settings.

Prerequisites

Before you begin, confirm the following:

• P0 account with the Owner role — You need the Owner role to manage policies, roles, and settings.

• The P0 Terraform provider, version 0.52.0 or later — Agentic access policies (the agent and user attributes) require 0.52.0. The p0_access_policy resource itself is available from 0.51.0, and the role-binding and JIT-settings resources from 0.50.0.

• A configured provider — You have declared and authenticated the p0 provider, as described in Get started with the P0 Terraform provider.

Declare the provider with a version that includes the policy resources:

terraform {
  required_providers {
    p0 = {
      source  = "p0-security/p0"
      version = "~> 0.52"
    }
  }
}

provider "p0" {
  org = "my-org"
}

The provider reads your token from the P0_API_TOKEN environment variable. See Get started with the P0 Terraform provider to authenticate, or Authenticating with the P0 API to get a token. A pipeline that applies policies or settings needs an identity with the Owner role.

The P0 API has no read endpoint for role assignments or JIT settings, so Terraform cannot detect drift on those resources after they are applied. Manage each setting in one place—Terraform or the dashboard—rather than both.

Manage access policies

An access policy controls who can request access to what, and what approvals the request needs. The p0_access_policy resource models one policy with three parts:

• requestor — who the policy matches (a directory group, a specific user, anyone, or an agent).

• resource — the integration and, optionally, the resource filters the policy applies to.

• approval — how requests are approved, as an ordered list of approval steps.

The resources a policy references must already exist in P0. For example, the Okta group must come from an installed Okta directory listing, the aws integration from an installed AWS account, and PagerDuty from an in-app connection.

The following policy lets members of an Okta group request AWS access, auto-approved through PagerDuty when they give a reason:

resource "p0_access_policy" "aws_developers_oncall" {
  name = "okta-aws-developers-oncall"

  requestor = {
    type   = "group"
    effect = "keep"
    groups = [{
      directory = "okta"
      id        = "00abcdefghijklmno697"
      label     = "AWS Developers"
    }]
  }

  resource = {
    type    = "integration"
    service = "aws"
    filters = {
      "tag" = {
        effect  = "keep"
        key     = "p0_grantable"
        pattern = "1|true"
      }
    }
  }

  approval = [{
    type        = "auto"
    integration = "pagerduty"
    options = {
      require_reason = true
    }
  }]
}

Match agent requestors

For agentic access policies, set requestor.type to agentic and describe the agent under agent. The user block describes the human behind the agent; use type = "none" to match headless agent sessions.

This policy denies access to a specific MCP client agent running without a human present:

resource "p0_access_policy" "mcp_agent_headless" {
  name = "mcp-agent-headless"

  requestor = {
    type = "agentic"
    agent = {
      type      = "agent-client"
      client_id = "my-agent-client"
    }
    user = {
      type = "none"
    }
  }

  resource = {
    type    = "integration"
    service = "aws"
  }

  approval = [{
    type = "deny"
  }]
}

The agent.type value selects how the policy matches an agent: any matches any agent, agent-client matches agents connecting through a specific gateway client, agent-owner matches an agent owned by a specific user, owner-group matches an agent owned by a member of a directory group, and provider matches an agent federated by an identity provider.

Manage P0 role assignments

The P0 RBAC roles map to eight role-binding resources—a user and a group variant for each of the four assignable roles:

Role	User resource	Group resource
Owner	p0_owner_user	p0_owner_group
Security Reviewer	p0_security_reviewer_user	p0_security_reviewer_group
Assessment User	p0_assessment_user	p0_assessment_group
Assessment Viewer	p0_assessment_viewer_user	p0_assessment_viewer_group

Each user resource takes an email, and each group resource takes a group:

resource "p0_owner_user" "admin" {
  email = "[e-mail]"
}

resource "p0_security_reviewer_group" "reviewers" {
  group = "eng-security"
}

Manage just-in-time access settings

Two singleton resources manage the organization's JIT access settings. Declare each at most once.

p0_access_durations sets the organization's duration policy. Each field takes a time (a whole number) and a unit (s, m, h, d, or w):

resource "p0_access_durations" "org" {
  # Maximum time between a request and its approval.
  approvable = {
    time = 14
    unit = "d"
  }

  # Maximum duration access may be granted for.
  max_access = {
    time = 180
    unit = "d"
  }

  # Maximum duration of standing (persistent) access before re-approval.
  standing_access = {
    time = 24
    unit = "h"
  }
}

p0_expiry_options sets the request-duration presets requestors can select:

resource "p0_expiry_options" "org" {
  options = [
    { time = 5, unit = "m" },
    { time = 1, unit = "h" },
    { time = 24, unit = "h" },
    { time = 168, unit = "h" },
  ]
}

Migrate from p0_routing_rule

Access policies were previously called routing rules, and the p0_routing_rule resource is now deprecated. It shares the same schema and behavior as p0_access_policy, but it will be removed in a future release. Migrate any existing p0_routing_rule resources to p0_access_policy.

To migrate without destroying and recreating the policy, rename the resource type and add a moved block, which requires Terraform 1.8 or later:

resource "p0_access_policy" "aws_developers_oncall" {
  name = "okta-aws-developers-oncall"
  # ...unchanged policy configuration...
}

moved {
  from = p0_routing_rule.aws_developers_oncall
  to   = p0_access_policy.aws_developers_oncall
}

Run terraform plan and confirm the plan reports a move rather than a create or destroy, then apply. After the move succeeds, you can remove the moved block.

Apply and verify

Apply your configuration:

terraform apply

Review the plan and confirm. To verify a policy applied, open Access Policies in the P0 dashboard and confirm the policy appears, or check the resource state:

terraform state show p0_access_policy.aws_developers_oncall

Confirm role assignments in Role-Based Access Control and JIT settings in the JIT access settings, both in the P0 dashboard.

Next steps

• Understand access policies — See Configure access policies for the concepts behind requestors, resources, and approvals.

• Read the resource reference — The full argument reference for each resource is in the Terraform Registry, including p0_access_policy, p0_access_durations, and p0_expiry_options.

• Install integrations as code — See Get started with the P0 Terraform provider to install integrations with the provider.