vbatts/cncf-toc
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Create Open Policy Agent Proposal for Review

Browse source
This commit is contained in:
Ken Owens 2017-11-27 15:29:30 -06:00 committed by GitHub
parent 0382094135
commit 27128476ba
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 182 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

182
proposals/Open Policy Agent Normal file
View file

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