diff --git a/proposals/opa.md b/proposals/opa.md new file mode 100644 index 0000000..3e08978 --- /dev/null +++ b/proposals/opa.md @@ -0,0 +1,182 @@ +# 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.