Authorization models · PBAC

Policy-based access control, as real code in your own repo

RBAC, ABAC, and ReBAC describe who gets access. PBAC is how you run it: authorization as policy code that is versioned, tested, reviewed, and shipped like the rest of your software. Permit generates Rego into your Git repository, lets you extend it with your own, and gives policy a release process.

Book a demo Start free

“OPAL has been a godsend for supporting dynamic OPA data and policy updates. The Permit.io have always been proactive in understanding my questions and providing the right answers. Giving OPAL a try is a no-brainer when looking for alternatives to traditional bundle servers.”

Jayanth VhavleSoftware Engineer, Walmart

Why policy as code stalls when you build it yourself

Running OPA is the easy part
Writing Rego is one job. Bundling it, distributing it, and keeping policy data fresh on every agent is another, and that one never ends.
Only the Rego authors can change policy
Product and security wait in line for the few engineers comfortable with a Datalog-style language.
Policy has no release process
A policy change goes straight to production, without a preview environment, a test run against real traffic, or a review.
The console and the repo disagree
Roles and resources clicked into an admin console drift away from what the code and the infrastructure definitions say.

How Permit does PBAC

Everyone edits the same policy. Engineers get the code, the repository, and the pipeline; everyone else gets an editor that writes that code for them.

Rego generated from the editor
Every RBAC, ABAC, and ReBAC rule configured in the no-code editor is generated as Open Policy Agent Rego you can read, diff, and review.
Your own Rego, alongside it
Add custom Rego next to the generated code, import the generated packages, and combine them, for example a deny rule that overrides any allow.
Your repository, one branch per environment
With GitOps, each Permit project maps to a Git repository and each environment to a branch, on GitHub, GitLab, or Bitbucket.
Terraform for the authorization model
Resources, actions, roles, relations, condition sets, and tenants defined as HCL, planned and applied like any other infrastructure.
Live sync to every decision point
OPAL pushes policy and data changes to OPA in real time, so there is no bundle server to build and no redeploy to wait for.

A custom Rego rule, overriding an allow

RBAC grants the temporary admin role. A custom deny rule limits it to its approved window. Illustrative data.

Example decisiondeny

subject: user:oncall@example.com (role: tmp-admin)
action: delete
resource: cluster:prod-eu
reason: RBAC allows tmp-admin; custom rule denies outside the access window
decided by: OPA in the PDP beside your service

The Rego behind it

Custom policy imports the generated packages. With the AND change in root.rego shown below, it can deny what the generated policy allows. Illustrative example.

custom/custom.rego

package permit.custom

import future.keywords.in
import data.permit.policies
import data.permit.rbac

default allow := false

allow {
    not "rbac" in policies.__allow_sources
} else {
    not "tmp-admin" in rbac.allowing_roles
} else {
    # tmp-admin only inside its approved window
    time.now_ns() >= time.parse_rfc3339_ns(input.user.attributes.access_start)
    time.now_ns() <= time.parse_rfc3339_ns(input.user.attributes.access_end)
}

Architecture diagram: policy from the no-code editor and custom Rego commits flows into a Git repository with dev, staging, and prod branches, then through OPAL to policy decision points beside each service. — Policy flows from the editor and your own Rego commits into Git, one branch per environment, and OPAL syncs it to every PDP in real time.

The policy life cycle, end to end

From the first line of Rego to the change that reaches production, every step has a place in your tooling.

Rego and OPA

Generated policy you can read, custom policy you can write

The policy repository is plain Rego, not a proprietary format. Permit writes its generated policy into one folder, you write yours into another, and a root policy decides how they combine.

Generated RBAC, ABAC, and ReBAC policy lives under permit/, and your custom Rego lives under custom/, in as many files and packages as you need.
By default root.rego allows when either the generated or the custom policy allows. Require both, and custom rules become deny rules.
Unit test policy with opa test, and debug custom rules with print(), which writes to the PDP logs.

root.rego

package permit.root

import data.permit.custom
import data.permit.policies

default allow := false

# Both must allow: custom rules can now deny
allow {
    policies.allow
    custom.allow
}

Terraform

The authorization model as infrastructure code

Some teams want authorization defined next to the services it protects. The Permit Terraform provider manages the model itself, so a new resource type or role ships in the same pull request as the service that needs it.

Resources and actions, attributes, roles, relations, role derivations, condition sets, user and resource sets, and tenants.
Works with Terraform 1.0 or later, and with OpenTofu.
Already built your model in the editor? permit env export terraform writes the whole environment out as HCL to start from.

main.tf

terraform {
  required_providers {
    permitio = {
      source = "registry.terraform.io/permitio/permit-io"
    }
  }
}

resource "permitio_resource" "document" {
  key  = "document"
  name = "Document"
  actions = {
    "read"  = { "name" = "Read" }
    "write" = { "name" = "Write" }
  }
}

resource "permitio_role" "reader" {
  key         = "reader"
  name        = "Reader"
  permissions = ["document:read"]
  depends_on  = [permitio_resource.document]
}

Policy life cycle

Branch, test, review, promote

Treat a policy change like a code change. Give it its own environment, prove it against real decisions, get it reviewed, then merge it into production.

Copy production into a preview environment for each policy change, through the API or the CLI.
Run unit tests on the Rego, and integration tests against a PDP synced to the preview environment.
permit test run audit replays recent real decisions against the new policy and flags any that come out differently.
Policy guards control who may change which policies, and the activity and API logs record every change.

release-policy.sh

# 1. Preview environment for this change
permit env copy --api-key "$PERMIT_API_KEY" \
  --from production --to pr-142

# 2. Unit test the Rego
opa test ./policy

# 3. Replay 24 hours of real decisions against it
permit test run audit --api-key "$PERMIT_API_KEY" \
  --pdp-url http://pdp-pr-142:7766 --time-frame 24

# 4. Reviewed and green: promote
permit env copy --api-key "$PERMIT_API_KEY" \
  --from pr-142 --to production

GitOps

Your Git repository is the source of truth

Connect a repository once. From then on, policy generated by the editor is committed there before it reaches your decision points, and what you push is what runs.

Each Permit project maps to a repository, and each environment to its own branch.
Connect GitHub, GitLab, or Bitbucket with an SSH deploy key that has write access.
Pushing to an environment’s branch updates that environment, and the policy repository does not have to be your application repository.

terminal

# Connect this environment to your GitHub repository
permit gitops create github

# Clone the environment's policy branch to work locally
permit gitops env clone

In their words

“Permit.io has helped us a lot to have a well-designed authorization platform based on open standards that we didn’t have to design ourselves.”

Malcolm LearnerSenior Solution Architect, Signify Health

“Moving to modern authorization for microservices is no easy feat, but OPAL made it easy. When I was learning and exploring replicator solutions for OPA myself in my free time, I found that OPAL is a very mature solution for the open-policy administration layer and beyond.”

Hongbo MiaoSenior Software Engineer, Tesla

Read the docs, run the code

Documentation

Example projects on GitHub

Questions about PBAC

What is policy-based access control?

PBAC manages authorization as explicit policies, evaluated by a policy engine on every request, instead of permission logic scattered through application code. The policies are kept as code, so they can be versioned, tested, and reviewed.

How does PBAC relate to RBAC, ABAC, and ReBAC?

They are models for deciding access: by role, by attribute, or by relationship. PBAC is how those rules are expressed and operated. In Permit, rules from all three models are generated as Rego and can be combined with custom policy.

Do we have to write Rego?

No. The no-code editor generates Rego for RBAC, ABAC, and ReBAC. Custom Rego is there for the rules the editor does not cover, such as deny rules that override other policies.

Can custom Rego deny access that other policies allow?

Yes. By default, access is allowed if either the generated or the custom policy allows it. Change root.rego to require both, and custom rules act as deny rules.

Can we manage Permit with Terraform?

Yes. The Permit Terraform provider manages resources, roles, relations, role derivations, condition sets, user and resource sets, and tenants, and the CLI can export an existing environment to Terraform.

Which Git providers work with GitOps?

GitHub, GitLab, and Bitbucket, or any provider that supports SSH deploy keys with write access.

Bring your hardest permission problem.

Tell us what you are authorizing and where it runs. We come to the call with a model of how Permit would enforce it.

Book a demo Read the docs

SOC 2 Type II attestedSecurity, Availability, Confidentiality
Cloud, hybrid, or on-premDecisions run in your network
Every decision loggedExplained, and forwardable to your SIEM
Built on open standardsOPA, Cedar, and OPAL

Review our security program in the Trust Center

Policy-based access control, as real code in your own repo

package permit.custom import future.keywords.in import data.permit.policies import data.permit.rbac default allow := false allow { not "rbac" in policies.__allow_sources } else { not "tmp-admin" in rbac.allowing_roles } else { # tmp-admin only inside its approved window time.now_ns() >= time.parse_rfc3339_ns(input.user.attributes.access_start) time.now_ns() <= time.parse_rfc3339_ns(input.user.attributes.access_end) }

terraform { required_providers { permitio = { source = "registry.terraform.io/permitio/permit-io" } } } resource "permitio_resource" "document" { key = "document" name = "Document" actions = { "read" = { "name" = "Read" } "write" = { "name" = "Write" } } } resource "permitio_role" "reader" { key = "reader" name = "Reader" permissions = ["document:read"] depends_on = [permitio_resource.document] }

# 1. Preview environment for this change permit env copy --api-key "$PERMIT_API_KEY" \ --from production --to pr-142 # 2. Unit test the Rego opa test ./policy # 3. Replay 24 hours of real decisions against it permit test run audit --api-key "$PERMIT_API_KEY" \ --pdp-url http://pdp-pr-142:7766 --time-frame 24 # 4. Reviewed and green: promote permit env copy --api-key "$PERMIT_API_KEY" \ --from pr-142 --to production

In their words

“Permit.io has helped us a lot to have a well-designed authorization platform based on open standards that we didn’t have to design ourselves.”

Malcolm LearnerSenior Solution Architect, Signify Health

“Moving to modern authorization for microservices is no easy feat, but OPAL made it easy. When I was learning and exploring replicator solutions for OPA myself in my free time, I found that OPAL is a very mature solution for the open-policy administration layer and beyond.”

Hongbo MiaoSenior Software Engineer, Tesla

Questions about PBAC

What is policy-based access control?

How does PBAC relate to RBAC, ABAC, and ReBAC?

Do we have to write Rego?

No. The no-code editor generates Rego for RBAC, ABAC, and ReBAC. Custom Rego is there for the rules the editor does not cover, such as deny rules that override other policies.

Can custom Rego deny access that other policies allow?

Yes. By default, access is allowed if either the generated or the custom policy allows it. Change root.rego to require both, and custom rules act as deny rules.

Can we manage Permit with Terraform?

Which Git providers work with GitOps?

GitHub, GitLab, and Bitbucket, or any provider that supports SSH deploy keys with write access.

Policy-based access control, as real code in your own repo

Why policy as code stalls when you build it yourself

Running OPA is the easy part

Only the Rego authors can change policy

Policy has no release process

The console and the repo disagree

How Permit does PBAC

Rego generated from the editor

Your own Rego, alongside it

Your repository, one branch per environment

Terraform for the authorization model

Live sync to every decision point

A custom Rego rule, overriding an allow

The Rego behind it

The policy life cycle, end to end

Generated policy you can read, custom policy you can write

The authorization model as infrastructure code

Branch, test, review, promote

Your Git repository is the source of truth

In their words

Read the docs, run the code

Documentation

Example projects on GitHub

Questions about PBAC

Bring your hardest permission problem.

Policy-based access control, as real code in your own repo

Why policy as code stalls when you build it yourself

Running OPA is the easy part

Only the Rego authors can change policy

Policy has no release process

The console and the repo disagree

How Permit does PBAC

Rego generated from the editor

Your own Rego, alongside it

Your repository, one branch per environment

Terraform for the authorization model

Live sync to every decision point

A custom Rego rule, overriding an allow

The Rego behind it

The policy life cycle, end to end

Generated policy you can read, custom policy you can write

The authorization model as infrastructure code

Branch, test, review, promote

Your Git repository is the source of truth

In their words

Read the docs, run the code

Documentation

Example projects on GitHub

Questions about PBAC

Bring your hardest permission problem.