9.2 KiB
Project Description
Every organization has unique policies that affect the entire stack. These policies are vital to long term success because they codify important requirements around cost, performance, security, legal regulation, and more. At the same time, organizations often rely on tribal knowledge and documentation to ensure that policies are enforced correctly. While these approaches are known to be error prone, they exist because systems frequently lack the flexibility and expressiveness required to automate policy enforcement.
The Open Policy Agent (OPA) is a general-purpose policy engine that enables unified, context-aware policy enforcement across the stack. OPA empowers administrators with greater control and flexibility so that organizations can automate policy enforcement at any layer.
At the core of OPA is a high-level declarative language (and runtime) that allows administrators to enforce policies across multiple domains such as API authorization, admission control, workload placement, storage, and networking. OPA’s language is purpose-built for expressing policy decisions. The language has rich support for processing complex data structures as well as performing search and aggregation across context required for policy decisions. The language also provides support for encapsulation and composition so that complex policies can be shared and re-used. Finally, the language includes a standard library of built-in functions for performing math operations, string manipulation, date/time parsing, and more.
With OPA, policy decisions are decoupled from applications and services so that policy logic can be modified easily and upgraded on-the-fly without requiring expensive, time consuming development and release cycles.
OPA provides simple APIs to offload policy decisions from applications and services. Policy decisions are computed by OPA and returned to callers as structured data. Callers integrate with OPA by executing policy queries that can include arbitrary input values. For example, an API gateway might supply incoming API requests as input and expect boolean values (representing allow/deny decisions) as output. On the other hand, a container orchestrator might supply workload resources as input and expect a map of clusters and weights to drive workload placement as output. See the appendix for sample policies that cover these use cases.
OPA itself is written in Go and can be integrated as a library, host-level daemon, or sidecar container. OPA provides APIs to load and manage policies as well as external data. Finally, OPA provides rich tooling to support the development, testing, and debugging of policies.
Since the initial release in July 2016, OPA’s mission has been to provide a powerful building block that enables policy-based control across the stack. OPA’s roadmap for the next 12 months includes improvements to the language, integration with Google’s CEL, expansion of the standard policy library, as well as continued hardening and performance optimization.
Sponsor from TOC: Ken Owens, Brian Grant
Preferred Maturity Level: Sandbox
License: Apache License v2
Source Control
https://github.com/open-policy-agent/opa https://github.com/open-policy-agent/library
External Dependencies
github.com/ghodss/yaml MIT License github.com/gorilla/mux BSD 3-clause "New" or "Revised" License github.com/mattn/go-runewidth MIT License github.com/olekukonko/tablewriter MIT License github.com/peterh/liner MIT License github.com/pkg/errors BSD 2-clause "Simplified" License github.com/sirupsen/logrus MIT License github.com/spf13/cobra Apache License 2.0 github.com/spf13/pflag BSD 3-clause "New" or "Revised" License golang.org/x/crypto/ssh/terminal BSD 3-clause "New" or "Revised" License golang.org/x/sys/unix BSD 3-clause "New" or "Revised" License gopkg.in/fsnotify.v1 BSD 3-clause "New" or "Revised" License gopkg.in/yaml.v2 Apache License 2.0
Initial Committers: Torin Sandall and Tim Hinrichs from Styra (since creation), Tristan Swadell from Google (since May 2017)
Infrastructure Requests: None initially. CI is currently hosted on Travis and covered by the free tier for open source projects. In the future, we would like to leverage CNCF test clusters for system testing integrations built as part of the OPA project.
Communication Channels: Slack: http://slack.openpolicyagent.org
Issue Tracker: https://github.com/open-policy-agent/opa/issues
Website: http://www.openpolicyagent.org
Release Methodology and Mechanics
We currently use numbered releases with the changelog and binaries published to https://github.com/open-policy-agent/opa/releases. The release process is partially automated with manual portions assisted by scripts. The current release process is documented here: https://github.com/open-policy-agent/opa/blob/master/docs/devel/RELEASE.md. The release schedule is somewhat ad-hoc, aligned around large feature boundaries.
Social Media Accounts: Twitter: https://twitter.com/openpolicyagent
Community Size and any Existing Sponsorship
Adopters: Netflix Medallia Schuberg Phillis Huawei More: At least one large financial institution and one large online retailer is testing OPA
Integrations: Kubernetes (Use cases: federated resource placement, admission control) Docker (Use cases: Docker engine authorization) Istio (Use cases: microservice API authorization) Linkerd (Use cases: microservice API authorization) OpenSDS (Use cases: storage scheduling) Terraform (Use cases: risk management on terraform plans) PAM (Use cases: SSH and sudo authorization) Cloud Foundry buildpack to enable microservice API authorization
Sponsors https://www.styra.com https://www.firebase.com (Google)
Numbers: 3 active contributors currently (2 from Styra, 1 from Google), with 8 other contributors over past 12 months. 80 stars 49 members on Slack 31 releases
Statement of Alignment with CNCF Mission
As cloud native technology matures and enterprise adoption increases, the need for policy-based control has become apparent. OPA provides a powerful building-block that enables fine-grained, expressive policy enforcement. As such, we think that OPA would be a great for fit for the CNCF
Benefits to the CNCF
The ecosystem must provide solutions to control who can do what across microservice deployments because legacy approaches to access control do not satisfy the requirements of modern environments. OPA provides a purpose-built language and runtime that can be used to author and enforce authorization policy. As such, we feel that OPA will complement the CNCF’s portfolio and help accelerate adoption of cloud native technology in enterprises. In the longer term, we think that enterprises will benefit from a unified approach to policy enforcement can be applied across the stack.
What does OPA need from the CNCF
OPA needs a well respected, vendor-neutral home that can help serve as a rallying point around policy as code. In addition to increased visibility, we hope that inclusion in the CNCF will foster communication between OPA and other projects in the ecosystem. As the project grows, we would want to leverage the CNCF’s expertise around project governance and community standards as those are fundamental to the long term success of the project.
The project does not have any infrastructure requests at this time. CI is currently hosted on Travis and covered by the free tier for open source projects. In the future, we would like to leverage CNCF test clusters for system testing integrations built as part of the OPA project.
Appendix A: REST API Authorization Example
This sample shows two simple rules that enforce an authorization policy on an API that serves salary data. In English, the policy says that employees can see their own salary and the salary of any of their reports.
allow { input.method = "GET" input.path = ["salary", employee_id] input.user = employee_id }
allow { input.method = "GET" input.path = ["salary", employee_id] input.user = data.management_chain[employee_id][_] }
The first rule allows employees to GET their own salary. The rule shows how you can use variables in rules. In that rule, employee_id is a variable that will be bound to the same value across the last two expressions.
The second rule allow employees to GET the salary of their reports. The rule shows how you can access arbirary context (e.g., JSON data) inside the policy. The data may loaded into the policy engine (and cached) or it may be external and fetched dynamically.
Appendix B: Cluster Placement Example
This sample shows a simple rule that generates a set of clusters that a workload may be deployed to. The workload is provided as input to policy. In English, the policy says that workloads must be placed on clusters that satisfy the workload’s jurisdiction requirements.
desired_clusters = {name | cluster = data.clusters[name] satisfies_jurisdiction(input.deployment, cluster) }
satisfies_jursidiction(deployment, cluster) { deployment.jurisdiction = "europe" startswith(cluster.region, "eu") } else { not deployment.jurisdiction }
This example shows how logic can be composed across rules and functions.