cncf-toc/proposals/opa.md

# 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.