From fadec1f97a71ef4d3a0b28ac1d7dc3e2eee61b37 Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Tue, 5 Dec 2017 09:09:39 -0600 Subject: [PATCH 1/3] Add OPA project proposal Signed-off-by: Chris Aniszczyk --- proposals/opa.md | 182 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 182 insertions(+) create mode 100644 proposals/opa.md diff --git a/proposals/opa.md b/proposals/opa.md new file mode 100644 index 0000000..0c0c2fc --- /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 + +**Preferred Maturity Level:** Inception + +**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. From 15f95f621388ff3f20b17365a96009d868a8666a Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Thu, 15 Mar 2018 16:35:17 -0700 Subject: [PATCH 2/3] Add Brian Grant as additional TOC sponsor --- proposals/opa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/opa.md b/proposals/opa.md index 0c0c2fc..42e9dfc 100644 --- a/proposals/opa.md +++ b/proposals/opa.md @@ -32,7 +32,7 @@ Since the initial release in July 2016, OPA’s mission has been to provide a po 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 +**Sponsor from TOC:** Ken Owens, Brian Grant **Preferred Maturity Level:** Inception From 925ff151ccddfc0abf9e6c18c84c5d1d30b47b8c Mon Sep 17 00:00:00 2001 From: Chris Aniszczyk Date: Tue, 20 Mar 2018 22:32:44 +0800 Subject: [PATCH 3/3] Sandbox --- proposals/opa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/opa.md b/proposals/opa.md index 42e9dfc..3e08978 100644 --- a/proposals/opa.md +++ b/proposals/opa.md @@ -34,7 +34,7 @@ of the standard policy library, as well as continued hardening and performance o **Sponsor from TOC:** Ken Owens, Brian Grant -**Preferred Maturity Level:** Inception +**Preferred Maturity Level:** Sandbox **License:** Apache License v2