How do you enable rapid deployment of innovative applications on top of Docker containers while still satisfying strict requirements from your InfoSec and compliance departments? The Open Policy Agent (OPA), an open-source tool, enables you to update and enforce policies without slowing down developers or modifying application code. In this talk, Justin Cormack (Security Engineer at Docker) and Torin Sandall (Co-founder of the OPA project) will show how you can leverage the integrations between Docker and OPA to enforce fine-grained policies in your organization's container platform while still allowing your developers to move quickly. This talk is targeted at engineers building and operating container platforms who are interested in security and policy enforcement. The audience can expect to take aware fresh ideas about how to enforce fine-grained security policies across their container platform.
6. ● Heterogeneity: many languages, protocols,
systems
● Dynamism: system changing, policies
changing
● How do you enforce and audit policy?
● Correctness, performance, cost
Challenges
7. Today we are going to talk about tools and
approaches for solving this problem!
Computers can help!
14. Example Implementation
business logic
authorization logic
def get_user_account(req):
if not authorized(req):
raise status(403)
return db.read_user_account(req.id)
def authorized(req):
if "support" in req.subject.groups:
for ticket in get_open_tickets(req.id):
if req.subject.user == ticket.assignee:
return True
return False
# other authorization logic...
15. Obvious questions...
def get_user_account(req):
if not authorized(req):
raise status(403)
return db.read_user_account(req.id)
def authorized(req):
if "support" in req.subject.groups:
for ticket in get_open_tickets(req.id):
if req.subject.user == ticket.assignee:
return True
return False
# other authorization logic...
What happens when the policy changes...
What if the policy requires additional context...
What if the customer requires control of the policy...
What if the policy was not implemented correctly...
What if you have 100+ services written in N langs...
17. OPA: general-purpose policy engine
Inception
Project started in 2016 at
Styra.
Goal
Unify policy enforcement
across the stack.
Use Cases
Admission control
Authorization
ACLs
RBAC
IAM
ABAC
Risk management
Data Protection
Data Filtering
Users
Netflix
Chef
Medallia
Cloudflare
State Street
Pinterest
Intuit
...and many more.
Today
CNCF project (Sandbox)
36 contributors
1.5K stars
400 slack members
20+ integrations
Open Policy Agent
18. OPA: general-purpose policy engine
Service
OPA
Policy
(Rego)
Data
(JSON)
Policy
Query
Policy
Decision
Enforcement
Request
21. OPA: general-purpose policy engine
Service
OPA
Policy
(Rego)
Data
(JSON)
Policy
Query
Policy
Decision
Enforcement
Request
Service refers to any one of:
● Custom service
● Kubernetes API server
● Message broker
● SSH daemon
● CI/CD pipeline script
22. OPA: general-purpose policy engine
Service
OPA
Policy
(Rego)
Data
(JSON)
Policy
Query
Policy
Decision
Enforcement
Request
Service refers to any one of:
● Custom service
● Kubernetes API server
● Message broker
● SSH daemon
● CI/CD pipeline script
Input can be any JSON value:
"alice"
["v1", "users", "bob"]
{"kind": "Pod", "spec": …}
Output can be any JSON value:
true
"request rejected"
{"servers": ["web1", "web2"]}
26. ● write rules not code
● re-use same policy across all applications and
languages
● support audit and testing
A better way to build policy
27. OPA: Integrations
Data Filtering
Admission Control “Restrict ingress hostnames for payments team.”
“Ensure container images come from corporate repo.”
API Authorization
“Deny test scripts access to production services.”
“Allow analysts to access APIs serving anonymized data.”
Data Protection
Linux PAM
SSH & sudo “Only allow on-call engineers to SSH into production servers.”
"Trades exceeding $10M must be executed between 9AM and
5PM and require MFA."
"Users can access files for past 6 months related to the region
they licensed."
28. ● allow developers to see effect of policy earlier
● show effect of policy as soon as possible
● have ability to move point of enforcement
around if it improves code
● test policy was enforced in production as well
“Shift left”
31. OPA: general-purpose policy engine
Service
OPA
Policy
(rego)
Data
(json)
Policy
Query
Policy
Decision
Enforcement
● Declarative Policy Language (Rego)
○ Can identity I do operation O on resource R?
■ ACLs, RBAC, IAM, ABAC
○ What invariants does workload W violate?
■ Enforce, audit, dry-run
○ Which records should bob be allowed to see?
■ Constraints on data
32. OPA: general-purpose policy engine
Service
OPA
Policy
(rego)
Data
(json)
Policy
Query
Policy
Decision
Enforcement
● Declarative Policy Language (Rego)
○ Can identity I do operation O on resource R?
■ ACLs, RBAC, IAM, ABAC
○ What invariants does workload W violate?
■ Enforce, audit, dry-run
○ Which records should bob be allowed to see?
■ Constraints on data
● Library, sidecar, host-level daemon
○ Policy and data are kept in-memory
○ Zero decision-time dependencies
33. OPA: general-purpose policy engine
Service
OPA
Policy
(rego)
Data
(json)
Policy
Query
Policy
Decision
Enforcement
● Declarative Policy Language (Rego)
○ Can identity I do operation O on resource R?
■ ACLs, RBAC, IAM, ABAC
○ What invariants does workload W violate?
■ Enforce, audit, dry-run
○ Which records should bob be allowed to see?
■ Constraints on data
● Library, sidecar, host-level daemon
○ Policy and data are kept in-memory
○ Zero decision-time dependencies
● Management APIs for control & observability
○ Bundle service API for sending policy & data to OPA
○ Status service API for receiving status from OPA
○ Log service API for receiving audit log from OPA
34. OPA: general-purpose policy engine
Service
OPA
Policy
(rego)
Data
(json)
Policy
Query
Policy
Decision
Enforcement
● Declarative Policy Language (Rego)
○ Can identity I do operation O on resource R?
■ ACLs, RBAC, IAM, ABAC
○ What invariants does workload W violate?
■ Enforce, audit, dry-run
○ Which records should bob be allowed to see?
■ Constraints on data
● Library, sidecar, host-level daemon
○ Policy and data are kept in-memory
○ Zero decision-time dependencies
● Management APIs for control & observability
○ Bundle service API for sending policy & data to OPA
○ Status service API for receiving status from OPA
○ Log service API for receiving audit log from OPA
● Tooling to build, test, and debug policy
○ opa run, opa test, opa fmt, opa deps, opa check, etc.
○ VS Code plugin, Tracing, Profiling, etc.
35. Hands on example with OPA
Accounts
OPA Bundle
Server
Policy + Tickets
GET /accounts/alice HTTP/1.1
Authorization: Bearer ...
Input
{
method: GET
path: [accounts, alice]
subject: {
user: janet
groups: [support]
}
}
Result
true (allow) or false (deny)
Data
{
tickets: {
alice: [
{assignee: janet},
{assignee: bob}
],
ken: [
{assignee: janet}
]
}
}
39. For example:
● valuable data on PVs must be retained 6 months after app is undeployed
● default reclaim policy is "delete" because clean-up is annoying
● admins want to grant exceptions for specific apps to use "retain" policy
Beyond the app
40. Kubernetes Admission Policy
package kubernetes.admission
import data.kubernetes.storageclasses
reclaim_exceptions = {"payments", "clickstream"}
# Generate an admission control violation error if...
deny["invalid reclaim policy requested by app"] {
# Input object is a PVC and ...
input.kind = "PersistentVolumeClaim"
# StorageClass specifies the "Retain" reclaim policy and...
name = input.spec.storageClassName
storageclasses[name].reclaimPolicy = "Retain"
# The app that owns the PVC is not whitelisted.
not reclaim_exceptions[input.labels["app"]]
}