kubernetes cluster to ensure: - resource naming strategy - required properties are always set - images come from approved repositories #2 Build an authorization mechanism for Microservices which: - delegated - scalable - flexible
fast ▪ Uses its two main components: ◦ Policies - written in OPA built-in language REGO ◦ Data - just json documents ▪ Exposes easy to integrate with REST Api To run: ▪ You need a single binary or a docker image ▪ Put your rego and data files in ./policies directory docker run -ti -p 8181:8181 \ -v $(pwd)/policies:/policies \ openpolicyagent/opa:latest run -w -s /policies
true { input.name = "John" input.city = "Warsaw" } allow = true { input.name = "Mark" input.city = "Cracow" } Input.json {"input":{"name":"John","city":"Cracow"}} • Organized in packages • Input - context to make a decision • Rules: ◦ Can have default values ◦ Are defined as a set of assertions ◦ Can be repeated with the same name • At least one rule has to be true
"Cracow"} ] } policy.rego package sample default allow = false allow = true { data.employees[e].name = input.name data.employees[e].city = input.city } • Simple JSON that can be loaded from: ◦ from file ◦ via Rest API • You can refer to it by data.[field]
for testing • Test should share same package • You can mock input data # opa test ./path/to/policies test_policy.rego package sample test_john_from_warsaw_is_approved { allow with input as {"name":"John", "city":"Warsaw"} } test_john_from_moon_is_rejected { not allow with input as {"name":"John", "city":"Moon"} } policy.rego package sample default allow = false allow = true { data.employees[e].name = input.name data.employees[e].city = input.city }
my kubernetes cluster. 1. I really like the idea of recommended labels, so should you. https://kubernetes.io/docs/concepts/overview/working-with-o bjects/common-labels/ 2. I don't trust images from unknown sources, so I will whitelist those I trust(or like more...). 3. Because I like naming strategy all hosts in your Ingress controller should contain namespace name. 4. Oh, and don't dare to create Pods without resource limits
non-compliant resource with an immediate feedback. 2. Allows to define Constraints as Native Kubernetes CRDs. 3. Works with Admission Controller Webhooks 4. Uses Open Policy Agent :)
as a StatefulSet ▪ ClusterRole and ClusterRoleBinding for Gatekeeper ▪ Custom Resource Definitions - ConstraintTemplates ▪ Default config ▪ Service # kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml
create another one to rule them all! Key takeaways: • How to build fine-grained, scalable access control mechanism for microservice? • How do I run OPA as a sidecar? • How can we build IAM-like policies?
▪ Delegate decisions to OPA by calling it whenever user performs some action ▪ Send required context to make decisions as an input ▪ Maintain policies in a central place What could Sample Input look like? ▪ Principal - Who is performing an action? ◦ Name of a user? ◦ Group user is part of? ◦ Json Web Token? ▪ Resource - What kind of resource action refers to? ◦ Name of a service? ◦ Name of REST resource? ▪ Action - How actually user wants to do? ◦ Get some data? ◦ List some objects? ◦ Update? Sounds familiar?
and data file from http location ▪ OPA instance (sidecar) keep its own copy of policies ▪ Policies and data file should be archived and compressed as tar.gz file ▪ You can enable it by providing configuration file OPA config file services: - name: demo url: http://hostname bundles: authz: service: demo resource: bundle.tar.gz polling: min_delay_seconds: 10 max_delay_seconds: 20
tomzoh
mochizuki875
toru_kubota
brainpadpr
philipz
carta_engineering
tetsuya28
ishikawa_satoru
furuton
naruoga
oracle4engineer
grimoh
eileencodes
chriscoyier
addyosmani
techseoconnect
aleyda
mojombo
shpigford
afnizarnur
tammielis
eitanlees
jnunemaker
tammyeverts
