diff --git a/proposals/Open Policy Agent b/proposals/Open Policy Agent deleted file mode 100644 index 0c0c2fc..0000000 --- a/proposals/Open Policy Agent +++ /dev/null @@ -1,182 +0,0 @@ -# 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.