OPA: The Cloud Native Policy Engine

@sometorin @OpenPolicyAgent
Open Policy Agent

Torin Sandall
@sometorin
● Open Policy Agent co-founder and core contributor
● Istio and Kubernetes policy-related features
● ❤ good restaurants Copenhagen

Policy decisions should be decoupled
from policy enforcement.

Treat policy as a separate concern.
...just like DB, messaging, monitoring,
logging, orchestration, CI/CD...

Gain better control and visibility over
policy throughout your system.

Everyone is affected by policy...

"QA must sign-off on
images deployed to the
production namespace."
"Restrict ELB changes to
senior SREs that are on-call."
"Analysts can read client data
but PII must be redacted."
"Give developers SSH access to
machines listed in JIRA tickets
assigned to them."

Policy enforcement is a fundamental
problem for your organization.

Tribal knowledge provides NO guarantee
that policies are being enforced.
"Tribal knowledge" is the know-how or collective wisdom of the organization.

It is expensive and painful to maintain
policy decisions that are hardcoded into
the app.

Service
OPA
Policy
(rego)
Data
(json)
OPA is an open source,
general-purpose policy
engine.
Policy
Query
Policy
Decision

Decisions are decoupled
from enforcement.
Service
OPA
Policy
(rego)
Data
(json)
Policy
Query
Policy
Decision
Enforcement

OPA is a host-local cache
for policy decisions.
Node
Service
OPA
Node
Service
OPA

Node
Service
OPA
Node
Service
OPA
Node
Service
Node
Host Failures
OPA
Node
Service
Node
Network Partitions OPA
Network
Network
Fate Sharing
✔ Low latency
✔ High availability

Service
OPA
Policy
(rego)
Data
(json)
Policy
Query
Policy
Decision
Policy and data are
stored in-memory.
No runtime dependencies
during enforcement.
Enforcement

details service
reviews service
ratings service
landing page service

Demo: Authorization
landingpage
ratings
details
reviews
Input
{
"method": "GET",
"path": ["reviews", "bob"],
"user": "alice"
}

Demo: Authorization
landingpage
ratings
details
reviews
Demo Policy
"Employees can see their own reviews and the
reviews of their subordinates."
"Employees can see their own PII. HR can
also see PII."

Declarative Language (Rego)
● Is user X allowed to call operation Y on resource Z?
● Which annotations must be added to new Deployments?
● Which users can SSH into production machines?

"Employees may read their own reviews and the reviews of
their subordinates."

"Employees may read their own reviews [...]"

Input
{"method": "GET",
"user": "bob"}

allow = true {
input.method = "GET"
input.path = ["reviews", employee_id]
input.user = employee_id
}
Input
{"method": "GET",
"user": "bob"}

allow = true {
input.path = ["reviews", "bob"]
input.user = "bob"
}
Input
{"method": "GET",
"user": "bob"}

allow = true {
input.method = "GET" # OK
input.path = ["reviews", "bob"] # OK
input.user = "bob" # OK
}
Input
{"method": "GET",
"user": "bob"}

allow = true {
}
Input
{"method": "GET",
"user": "alice"}
"alice" instead of "bob"

allow = true {
"alice" = "bob" # FAIL
}
Input
{"method": "GET",
"user": "alice"}

allow = true {
"alice" = "bob" # FAIL
}
"Employees may read [...] the reviews of their subordinates."
Input
{"method": "GET",
"user": "alice"}

allow = true {
}
Input
{"method": "GET",
"user": "alice"}
Data (in-memory)
{"manager_of": {
"bob": "alice",
"alice": "janet"}}

allow = true {
}
allow = true {
input.user = data.manager_of[employee_id]
}
Input
{"method": "GET",
"user": "alice"}
Data (in-memory)
{"manager_of": {
"bob": "alice",
"alice": "janet"}}

allow = true {
}
allow = true {
input.user = data.manager_of["bob"]
}
Input
{"method": "GET",
"user": "alice"}
Data (in-memory)
{"manager_of": {
"bob": "alice",
"alice": "janet"}}

allow = true {
}
allow = true {
input.user = "alice"
}
Input
{"method": "GET",
"user": "alice"}
Data (in-memory)
{"manager_of": {
"bob": "alice",
"alice": "janet"}}

allow = true {
}
allow = true {
input.user = "alice" # OK
}
Input
{"method": "GET",
"user": "alice"}
Data (in-memory)
{"manager_of": {
"bob": "alice",
"alice": "janet"}}

What about RBAC?

RBAC solves XX% of the problem.

RBAC is not enough.
"QA must sign-off on images
deployed to the production
namespace."
"Analysts can read client data but
PII must be redacted."
"Restrict employees from accessing
the service outside of work hours."
"Allow all HTTP requests
from 10.1.2.0/24."
"Restrict ELB changes to senior
SREs that are on-call."
"Give developers SSH access to machines
listed in JIRA tickets assigned to them."
"Prevent developers from running
containers with privileged security
contexts in the production
namespace." "Workloads for euro-bank must be
deployed on PCI-certified clusters in
the EU."

...but everyone knows RBAC.

Implement RBAC with OPA.
Data (in-memory)
bindings:
- user: inspector-alice
role: widget-reader
- user: maker-bob
role: widget-writer
roles:
- operation: read
resource: widgets
name: widget-reader
- operation: write
resource: widgets
name: widget-writer

Data (in-memory)
bindings:
role: widget-reader
- user: maker-bob
role: widget-writer
roles:
- operation: read
resource: widgets
name: widget-reader
- operation: write
resource: widgets
name: widget-writer
allow = true {
# Find binding(s) for user.
binding := data.bindings[_]
input.user = binding.user

Data (in-memory)
bindings:
role: widget-reader
- user: maker-bob
role: widget-writer
roles:
- operation: read
resource: widgets
name: widget-reader
- operation: write
resource: widgets
name: widget-writer
allow = true {
# Find role(s) with permission.
role := data.roles[_]
input.resource = role.resource
input.operation = role.operation

Data (in-memory)
bindings:
role: widget-reader
- user: maker-bob
role: widget-writer
roles:
- operation: read
resource: widgets
name: widget-reader
- operation: write
resource: widgets
name: widget-writer
allow = true {
# Check if binding matches role.
role.name = binding.role
}

Data (in-memory)
bindings:
role: widget-reader
- user: maker-bob
role: widget-writer
roles:
- operation: read
resource: widgets
name: widget-reader
- operation: write
resource: widgets
name: widget-writer
Find bindings and
roles that match
input.
This rule searches over the RBAC data.
allow = true {
}

Partial Evaluation: rules + data ⇒ simplified rules
allow = true {
}
Data (in-memory)
bindings:
role: widget-reader
- user: maker-bob
role: widget-writer
roles:
- operation: read
resource: widgets
name: widget-reader
- operation: write
resource: widgets
name: widget-writer
Partial Eval
allow = true {
input.user = "bob"
input.resource = "/widgets"
input.operation = "write"
}
allow = true {
input.operation = "read"
}

allow = true { ... }
# Many rules (100s, 1000s)
allow = true {
}
OPA builds an index from simplified rules.
input.resource
input.operation
input.user
... ...
"read" "write"
"/widgets"
"alice" "bob"
input.resource
Rule Indexing
Rule Rule

OPA uses the index to quickly find applicable rules.
input.resource
input.operation
input.user
Rule
... ...
Rule
"read" "write"
"/widgets"
"alice" "bob"
input.resource
Query
allow
Input
{
"user": "alice",
"resource": "/widgets",
"operation": "read"
}

OPA only evaluates applicable rules.
input.resource
input.operation
input.user
Rule
... ...
Rule
"read" "write"
"/widgets"
"alice" "bob"
input.resource
# Many rules (100s, 1000s)
allow = true {
}
OPA ignores these.

# Roles # Bindings Normal Eval (ms) With Partial Eval (ms)
250 250 5.50 0.0468
500 500 11.87 0.0591
1,000 1,000 21.64 0.0543
2,000 2,000 45.49 0.0624
blog.openpolicyagent.org
Partial Evaluation https://goo.gl/X6Qu6u
Rule Indexing https://goo.gl/uoSw3U

Use OPA to enforce
policy across the stack.

It's all just data. deny {
is_read_operation
is_pii_topic
not in_pii_consumer_whitelist
}
operation: Read
resource:
name: credit-scores
resourceType: Topic
session:
principal:
principalType: User
name: CN=anon_producer,O=OPA
clientAddress: 172.21.0.5
deny {
not metadata.labels["qa-signoff"]
metadata.namespace == "prod"
spec.containers[_].privileged
}
metadata:
name: nginx-149353-bvl8q
namespace: production
spec:
containers:
- image: nginx
name: nginx
securityContext:
privileged: true
nodeName: minikube
allow {
input.path = ["salary", user]
input.user = user
}
method: GET
path: /salary/bob
service.source:
service: landing_page
service.target:
service: details
user: alice
allow {
score = risk_budget
count(plan_names["aws_iam"]) == 0
blast_radius < 500
}
aws_autoscaling_group.lamb:
availability_zones#: '1'
availability_zones.3205: us-west-1a
desired_capacity: '4'
launch_configuration: kitten
wait_for_capacity_timeout: 10m
aws_instance.puppy:
ami: ami-09b4b74c
instance_type: t2.micro

● Complex environment
○ >1,000 services
○ Many resource and identity types
○ Many protocols, languages, etc.
● Key requirements
○ Low latency
○ Flexible policies
○ Ability to capture intent
● Using OPA across the stack
○ HTTP and gRPC APIs
○ Kafka producers
○ SSH (coming soon)
User Study: Netflix
How Netflix is Solving Authorization Across Their Cloud
(KubeCon US 2017)

orchestrator
API
ssh
app
host
container
dbcloud
20+ companies using OPA. Financial institutions,
service providers, IT companies, software vendors, etc.
Used across the stack. Microservices, orchestration,
provisioning, host daemons, data layer, security groups, etc.
Bring more use cases. RBAC, ABAC, admission
control, data protection, risk management, rate liming, auditing, etc.

Demo

Try tutorials at openpolicyagent.org
HTTP API Authorization Admission Control Risk Management
SSH and sudoData Protection

Leverage OPA to solve fundamental
policy and security problems.

Thank You!
open-policy-agent/opa
Star us on GitHub.

OPA: The Cloud Native Policy Engine

More Related Content

What's hot

What's hot (20)

Similar to OPA: The Cloud Native Policy Engine

Similar to OPA: The Cloud Native Policy Engine (20)

Recently uploaded

Recently uploaded (20)

OPA: The Cloud Native Policy Engine