An open source, general-purpose policy engine.
Clone or download
tsandall Fix unsafe support calls
The inlining changes introduced a bug in the support calls that are made
when the negation cannot be inlined. The support rule was being created
with one argument for each unknown in the entire save set. Since some of
those variables may not be preserved in the final result, it was
possible for the support call to become unsafe. To resolve this we only
add call args for the intersection of unknowns and vars that appear in
the result of partially evaluating the negated expression.

Signed-off-by: Torin Sandall <>
Latest commit a862c08 Sep 21, 2018
Failed to load latest commit information.
ast Inline negated expressions during partial eval Sep 20, 2018
build Refactor Makefile perf targets Aug 6, 2018
bundle Update bundle reader to cap buffer size Sep 4, 2018
cmd Add deps subcommand Aug 21, 2018
cover Add Rego profiler Jul 3, 2018
dependencies Update analysis to mark input as base document Aug 21, 2018
design Updates to the Rego v2 proposal based on last design meeting. Feb 23, 2018
docs Add `regex.template_match` built-in Sep 20, 2018
format Update format package to tolerate nil locations Aug 30, 2018
internal/presentation Update format package to tolerate nil locations Aug 30, 2018
loader Add support for command line bundle loading Aug 8, 2018
logo Copy logo.svg into logo directory Apr 24, 2018
metrics Add marshalling to the metrics.Metrics package Jul 26, 2018
misc/syntax Add README for editor support directory Mar 22, 2018
plugins Added ability to dynamically load .so objects and the respective requ… Aug 16, 2018
profiler Add profiler to OPA eval command Jul 20, 2018
rego Refactor save set to support namespacing Aug 2, 2018
repl Add message when rule defined in REPL Sep 18, 2018
runtime Added ability to dynamically load .so objects and the respective requ… Aug 16, 2018
server Validate queries by checking unsafe builtins Sep 4, 2018
storage Remove dead code Jul 2, 2018
test scheduler_test: take GOPATH from "go/build" Jul 2, 2018
tester Update test runner to set Fail to true Sep 17, 2018
topdown Fix unsafe support calls Sep 21, 2018
types Improve call result handling Feb 17, 2018
util Added ability to dynamically load .so objects and the respective requ… Aug 16, 2018
vendor Vendoring: Feb 9, 2018
version Move versioning into Makefile Oct 17, 2016
watch fix misspell Jun 5, 2018
.dockerignore Add support for Docker image build Oct 18, 2016
.gitignore Modified .gitignore to ignore GoLand IDE files Dec 22, 2017
.travis.yml Refactor Makefile perf targets Aug 6, 2018 To the extent its helpful (reject change, if not), I'm adding specifi… Aug 21, 2018 Prepare v0.9.2 development Aug 16, 2018 Update code of conduct for CNCF Apr 2, 2018 commits must be signed off Aug 13, 2018 Update build to enable CGO Jul 9, 2018 Update build to enable CGO Jul 9, 2018 Refresh OPA website Jul 5, 2017 Define governance model for OPA Jun 7, 2018
LICENSE Initial commit Dec 28, 2015 Add May 12, 2017
Makefile Prepare v0.9.2 development Aug 16, 2018 Update the calendar invite for OPA bi-weekly meeting Sep 10, 2018
SECURITY_AUDIT.pdf Add external security audit information Aug 30, 2018 Add security vulnerability reporting process May 10, 2018
glide.lock Vendoring: Feb 9, 2018
glide.yaml Vendoring: Feb 9, 2018
main.go Rename the language to Rego May 9, 2016

logo Open Policy Agent

Slack Status Build Status Go Report Card CII Best Practices

The Open Policy Agent (OPA) is an open source, general-purpose policy engine that enables unified, context-aware policy enforcement across the entire stack.

OPA is hosted by the Cloud Native Computing Foundation (CNCF) as a sandbox level project. If you are an organization that wants to help shape the evolution of technologies that are container-packaged, dynamically-scheduled and microservices-oriented, consider joining the CNCF. For details read the CNCF announcement.

Want to learn more about OPA?

Want to get OPA?

Want to integrate OPA?

  • See GoDoc to integrate OPA with services written in Go.
  • See REST API to integrate OPA with services written in other languages.

Want to contribute to OPA?

How does OPA work?

OPA gives you a high-level declarative language to author and enforce policies across your stack.

With OPA, you define rules that govern how your system should behave. These rules exist to answer questions like:

  • Can user X call operation Y on resource Z?
  • What clusters should workload W be deployed to?
  • What tags must be set on resource R before it's created?

You integrate services with OPA so that these kinds of policy decisions do not have to be hardcoded in your service. Services integrate with OPA by executing queries when policy decisions are needed.

When you query OPA for a policy decision, OPA evaluates the rules and data (which you give it) to produce an answer. The policy decision is sent back as the result of the query.

For example, in a simple API authorization use case:

  • You write rules that allow (or deny) access to your service APIs.
  • Your service queries OPA when it receives API requests.
  • OPA returns allow (or deny) decisions to your service.
  • Your service enforces the decisions by accepting or rejecting requests accordingly.

The examples below show different kinds of policies you can define with OPA as well as different kinds of queries your system can execute against OPA. The example queries are executed inside OPA's REPL which was built to make it easy to develop and test policies.

For concrete examples of how to integrate OPA with systems like Kubernetes, Terraform, Docker, SSH, and more, see

Example: API Authorization

This example shows how you can enforce access controls over salary information served by a simple HTTP API. In this example, users are allowed to access their own salary as well as the salary of anyone who reports to them.

allow {
    input.method = "GET"
    input.path = ["salary", id]
    input.user_id = id

allow {
    input.method = "GET"
    input.path = ["salary", id]
    managers = data.management_chain[id]
    id = managers[_]

Example Queries

Is someone allowed to access their own salary?

> input = {"method": "GET", "path": ["salary", "bob"], "user_id": "bob"}
> allow

Display the management chain for Bob:

> data.management_chain["bob"]

Is Alice allowed to access Bob's salary?

> input = {"method": "GET", "path": ["salary", "bob"], "user_id": "alice"}
> allow

Is Janet allowed to access Bob's salary?

> input = {"method": "GET", "path": ["salary", "alice"], "user_id": "janet"}
> allow

Example: App Placement

This example shows how you can enforce where apps are deployed inside a simple orchestrator. In this example, apps must be deployed onto clusters that satisfy PCI and jurisdiction requirements.

app_placement[cluster_id] {
    cluster = data.clusters[cluster_id]
    satisfies_jurisdiction(, cluster)
    satisfies_pci(, cluster)

satisfies_jurisdiction(app, cluster) {
    not app.tags["requires-eu"]

satisfies_jurisdiction(app, cluster) {
    startswith(cluster.region, "eu-")

satisfies_pci(app, cluster) {
    not app.tags["requires-pci-level"]

satisfies_pci(app, cluster) {
    level = to_number(app.tags["requires-pci-level"])
    level >= cluster.tags["pci-level"]

Example Queries

Where will this app be deployed?

> input = {"app": {"tags": {"requires-pci-level": "3", "requires-eu": "true"}}}
> app_placement

Display clusters in EU region:

> startswith(data.clusters[cluster_id].region, "eu-")
| cluster_id |
| "prod-eu"  |
| "test-eu"  |

Display all clusters:

> data.clusters[cluster_id]
| cluster_id |           data.clusters[cluster_id]            |
| "prod-eu"  | {"region":"eu-central","tags":{"pci-level":2}} |
| "prod-us"  | {"region":"us-east"}                           |
| "test-eu"  | {"region":"eu-west","tags":{"pci-level":4}}    |
| "test-us"  | {"region":"us-west"}                           |

Example: SSH Auditing

This example shows how you can audit who has SSH access to hosts within different clusters. We will assume that SSH access is granted via group access in LDAP.

import data.ldap
import data.clusters

ssh_access[[cluster_name, host_id, user_id]] {
    host_id = clusters[cluster_name].hosts[_]
    group_id = ldap.users[user_id].groups[_]
    group_id = clusters[cluster_name].groups[_]

prod_users = {user_id | ssh_access[["prod", _, user_id]]}

Example Queries

Who can access production hosts?

> prod_users

Display all LDAP users:

> data.ldap.users[user_id]
|   data.ldap.users[user_id]    | user_id |
| {"groups":["dev","platform"]} | "alice" |
| {"groups":["dev","ops"]}      | "bob"   |
| {"groups":["dev"]}            | "janet" |

Display all cluster/group pairs:

> data.clusters[cluster_id].groups[_] = group_id
| cluster_id |  group_id  |
| "test"     | "dev"      |
| "test"     | "ops"      |
| "prod"     | "ops"      |
| "prod"     | "platform" |

Does Janet have access to the test cluster?

> ssh_access[["test", _, "janet"]]

What are the addresses of the hosts in the test cluster that Janet can access?

> ssh_access[["test", host_id, "janet"]]; addr = data.hosts[host_id].addr
|    addr    |  host_id   |
| "" | "host-abc" |
| "" | "host-cde" |
| "" | "host-efg" |

Further Reading


  • Open Policy Agent Introduction @ CloudNativeCon EU 2018: video, slides
  • Rego Deep Dive @ CloudNativeCon EU 2018: video, slides
  • How Netflix Is Solving Authorization Across Their Cloud @ CloudNativeCon US 2017: video, slides.
  • Policy-based Resource Placement in Kubernetes Federation @ LinuxCon Beijing 2017: slides, screencast.
  • Enforcing Bespoke Policies In Kubernetes @ KubeCon US 2017: video, slides.
  • Istio's Mixer: Policy Enforcement with Custom Adapters @ CloudNativeCon US 2017: video, slides.


Security Audit

A third party security audit was performed by Cure53, you can see the full report here

Reporting Security Vulnerabilities

Please report vulnerabilities by email to open-policy-agent-security. We will send a confirmation message to acknowledge that we have received the report and then we will send additional messages to follow up once the issue has been investigated.