The document discusses authorization in microservices, focusing on the roles of Istio and Open Policy Agent (OPA). Key points include the significance of externalizing authorization from code, the evolution of access control mechanisms, and how OPA allows for declarative policy management that can easily adapt to various platforms. It emphasizes the benefits of using OPA to streamline policy decisions without requiring code redeployment.

1. Authorization in Micro Services world
ISTIO and Open Policy Agent
Sitaraman Lakshminarayanan

2. About Me
• Sitaraman Lakshminarayanan
• Work: Security Architect at Pure Storage
• Books : Author Oracle Web Services Manager,
Co-Author ASP.NET Security
• Twitter @Lsitaraman

3. Definitions
• Role Based Access Control
– Define Roles
– Roles map directly to API endpoints or via Permissions
• Attribute Based Access Control
– User’s Age, Title, Location / IP , etc.
– Combination of In line code + external api call.
• Policy Based Access Control
– Describes what User/Role or Group can perform what
Actions on a resource under certain conditions. E.g.
AWS IAM

4. What we will cover are..
• Role Based Access Control – Client /Server
App and its Challenges
• Web Based / Service Oriented Architecture
model and its Challenges
• Externalizing Authorization and how it can
address your Access Control needs
• One big idea is how Open Policy Agent can
help

5. RBAC in Client Server Applications –
‘late 90s

6. Authorization Logic in the Code
Function
Button_SaveCustomer_Clicked()
{
If ( Form.Name == “CreateCustomer” )
{
if ( LoggedInUser.Role !=
“CustomerAdmin” )
{
Exception “Access
Denied”
}
}
}

7. • Three Tier Architecture – early to mid 2000’s
AuthZ code on Web
Server before Page
is rendered / when
Submitted Trust relationship –
Firewall, Custom
Headers, etc.
Web Access
Management that
Protects URL
Patterns

8. API Gateway

9. API Gateway with Internal
Services
A
P
I
G
a
t
e
w
a
y
Business Domain -
Web Service 1
Business Domain Web
Service 2
Business Domain Web
Service 3
Internal
API
Gateway
DB CRUD
Service
Internal
Service2
Web App
Mobile App
WS-Security / SAML/WS-Trust Internal AuthN / AuthZ

10. SOA + Gateway
• Authorization enforcement at different places
– API Gateway
– Internal Gateway
– At Service /endpoint for any Business Specific ACL
• Makes it harder to change Authorization Rules
without changing code
• Or Every AuthZ decision is pushed to Gateway
making Gateway
– Bloated , Monolithic and Bureaucratic

11. API Gateway – Before CI/CD

12. But REST API will solve ...
• Oh well not really
• We moved from XML to JSON
• JWT - JSON Web Token
– JSON data
– Digitally Signed
– Represents User Information, May be Roles/
Scopes

13. REST API + JWT + HTTP Filter

14. What’s the issue with filters?
• Hard to change API to
Role/Permission without
changing Code
• Any Code change would
require regression testing
• But Gateway’s are hard to
manage, more overhead
and takes time

15. How do we move forward?
• Externalize Authorization from Code
– Not Just Gateway that acts as Check Point
– Making it developer friendly and easy to develop,
deploy and change policies.
• Externalizing Authorization from code is not
new
– API Gateway was one such solution
– Extensible Access Control Markup Language
(XACML) standard was supposed to address this.

16. XACML to the rescue
• Extensible Access Control Markup Language –
first attempt towards externalizing Policy
Decisions in a standardized manner.

17. XACML and API Integration
Policy Decision Point
that makes decisions
Policy enforcement
point – Integrates with
your API and PDP to
get decisions

18. XACML retrospective
• Pros
– Externalized Authorization from code
– Policies can be developed and deployed outside of
Code
• Cons
– XACML integration required learning specific
syntax
– Not much open source integration

19. XACML Replacement – Build
your own AuthZ API
• Build your own Authorization API
• Integrations between AuthZ API and
App/Service are proprietary

20. Custom Authorization Decision
API

21. When you build your own
AuthZ API
• You own everything
– Contract between Client and Authorization API /
Policy Decision Point
– Build SDK for languages within your enterprise
– Train every developer on your own API and
Integration, no community to source information
from
– Suddenly you are asking yourself – Am I Building
Feature X? or Am I a Security product?

22. Kubernetes Authorization
Kubernetes API
Server
Kubernetes
Dashboard
Kubernetes CLI -
Kubectl
RBAC- Role
based
Custom – Web
Hook
ABAC – Attribute
Based

23. Kubernetes Web Hook
Authorization
• To Make Authorization Decision, you need
– Resource being accessed
– Action being perform ( GET, POST, etc.)
– Incoming User Identity / Token
• Write Web Hook that return Allow or Deny
• Enable Web Hook Authorization with
Kubernetes Framework
• Now every request to Kubernetes API will
invoke the Web Hook for Authorization

24. Example Web Hook AuthZ in
K8
{ "apiVersion":
"authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec":
{ "resourceAttributes":
{ "namespace":
"kittensandponies",
"verb": "get",
"group":
"unicorn.example.org",
"resource":
"pods"
},
"user": "jane",
"group": [ "group1",
"group2" ]
}}
K8 API Version, so you can
make decision based on
Version of K8 API Server
Kind –
SubjectAccessReview
Describes type of Object.
Provides flexibility to add
any other review later.
ResourceAttributes – tells
everything you need to know.
What namespace being
accessed, whether its HTTP
get or post , user identity and
Group information ( can
come from JWT Token from
your SSO System, etc.)

25. AuthZ Decision
{ "apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status":
{
"allowed": true
}
}
Unified Response
format to tell K8 if
request is allowed
or denied.

26. Why I love K8 AuthZ model
• You let customers manage their own Risk. You
provide the framework.
• No one size fits all RBAC model
• Its designed with API First approach – so
everything is a Resource.
• Externalized Authorization through Web Hook
let you manage the Risk, implement Policy and
Process around your deployment.

27. What about Services deployed
on K8
• Micro Services have gained huge adoption and
its much easier with Kubernetes.
• But you still have to manage Authorization for
your Business Services.
• ISTIO brings together faster deployment and
Gateway approach for Services.

28. ISTIO overview

29. ISTIO Things to know
• Without going into ISTIO jargons… ISTIO makes it
easy to
– Enforce Authorization
– Logging
– Collect Telemetry
– Quotas
– Deploys Envoy Proxy as SideCar
• In other words, ISTIO is light weight proxy in front
of your API Services
• ISTIO components are at Ingress and Egress layer

30. ISTIO Authorization
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: tester
namespace: default
spec:
rules:
- services: ["test-*"]
methods: ["*"]
- services:
["bookstore.default.svc.cluster.local"
]
paths: ["*/reviews"]
methods: ["GET"]
Authorization now
moved from Code /
Gateway config to
YAML .. We all love
Yet another.. 
Fine Grained ACL gets
challenging.
This is external to
code but still requires
re-deployment.

31. ISTIO Service to Service
Deploying ISTIO completely
hides the complexity of
Service Discovery and
Service Invocation
mTLS, Protocol Translation,
etc.
But what about
Authorization?- YAML file


32. Externalizing AuthZ in Micro Services World
• Let’s agree to a standard of communicating
– Resource ( end point being invoked)
– Operations / Actions being performed
– Identity of Caller
– Payload
• You can use your own proprietary, or Platform
Specific or use Open Policy Agent

33. Open Policy Agent
• It’s a Policy Engine
• Available as RESTful API with JSON and HTTP ,
so no new integration patterns.
• Data can be static or Dynamic that can be
used to make the decision
• Policies are written in declarative language
Rego
• Policies are updated in OPA via /v1/policies
API endpoint

34. OPA
Authorization Logic

35. OPA-Rego and Policies
• OPA uses its native query language Rego
• Policy decisions are written in Rego
• Policies are defined inside Module.
– Each Module should have one Package name
– Zero or more statements
– Zero or more Rules

36. OPA Policy Walkthrough
Package Name
Rule Name
Compares Input – If method is
GET, Path is finance and
Username , if everything is true it
returns True.
Input is keyword. Assign Input as
http_api variable
package httpapi.authz
subordinates = {"alice": [], "charlie": [],
"bob": ["alice"], "betty": ["charlie"]} Static Data
import input as http_api
allow {
http_api.method = "GET"
http_api.path = ["finance",
"salary", username]
username = http_api.user }

37. How is OPA Policy invoked?
input_dict =
{ # create input to hand to OPA "input":
{ "user": api_user_from_jwt,
"path": “finance”,
"method": “GET”
}
}
rsp =
requests.post("http://example.com/v1/data/htt
papi/authz", data=json.dumps(input_dict))
if rsp.json()["allow"]
Gather Input.
HTTP Filter that gathers all
the data such as User ,
Method, URL Path, etc.
Make a Call to OPA - POST
v1/data/{PolicyName} and
supply the Input, get a
decision back as JSON
JSON is returned with
allow:True or can be any
specific data

38. OPA and API Authorziation

39. OPA Integration Architecture

40. OPA - Benefits
• You can update the Policy without changing
Code
• Policy definition can be left to development
teams to implement, but just outside of the
core Business API
• It can be used beyond REST API – Anywhere
there can be a Plugin, OPA can be integrated
as Plugin.

41. Micro Services, ISTIO and OPA
• API’s are deployed in Kubernetes
• ISTIO runs as Side Car
• OPA Plugin for ISTIO makes Policy Decision
Queries against OPA

42. Key Takeaways
• Externalize Authorization from code
• OPA provides easy way to write Policies and
Integrate via API
• REST API integration with Policy Decision makes it
easier to adapt across Platforms – Java, Node,
Python, etc.
• Policies and Data can be made available as
Bundle.
• Policy Change does not require re deployment of
code.

43. Questions?
• Thanks to K8 and OPA Community
• Various Authors who blogged about OPA
Thank You