Sitaraman Lakshminarayanan Sr Security Architect at Pure Storage Authorization has two components – Policy Definition and Policy Enforcement. Traditionally both used to be centralized and we spent all the time Integrating products- Built or Bought with Centralized Access Management. This typically led to increased cycle time to change any access policy or change software/deployment to fit into one particular authorization model. When that doesn’t fit, we would end up with multiple authorization enforcements written in different languages with or without any adherence to any standards such as XACML or others. Imagine building few different or hundreds of products or services or micro services and you have to centrally manage all possible access policies. It’s definitely not a scalable solution in fast moving CI/CD world. Now imagine a way where every developers or products can externalize its authorization and we can modify authorization enforcement in a consistent manner? Imagine where developers can write their own implementation of how authorization should be enforced for their environment? Remember there is no one size fits all authorization policy. A policy that works for your environment does not work for my environment – for any number of reasons from Risk management to type of business applications. Open Policy Agent provides a consistent way to write authorization logic and expose it as REST API. Applications can easily integrate with OPA and can also write their own authroziation logics. Whether you are shipping products to customers or integrating a Product or Service into your environment, how awesome it would be to enforce your own authorization rules instead of changing your business process of who can gain access to what features. In this talk we will explore the benefits of Decentralized Authorization and how to use Open Policy Agent to achieve decentralized authorization. A closer look at few applications /integrations whether it is REST API /Micro Services, or Kubernetes to control various authorization policies as to who can deploy/what can you deploy. We will also look at how to build Integration tests to check our authorization policies.

1. Seattle | September 16-17, 2019
Decentralized Authorization
SITARAMAN
LAKSHMINARAYANAN

2. Seattle | September 16-17, 2019
Am I Authorized to speak about this topic? OR whoami ?
• Subject – Sitaraman ( Ram) Lakshminarayanan
• Resources – I work for Pure Storage as Sr Security Architect
• Actions – Author-Web Services Security, Co-Author ASP.NET Security
• Other Attributes: Twitter: @Lsitaraman , Exp : 20 Years, Can speak Role
Based and Fine Grained Authorization semantics among other things.

3. Seattle | September 16-17, 2019
Why talk about Authorization here?
• Security Teams are always in the mix between – Developers / Operations /
Customers/ PM’s.
• Let’s not just ask questions, provide solutions.
• Just pointing in the right direction is a big favor to developers.

4. Seattle | September 16-17, 2019
What is Authorization?
Subject – User / Application
Resource – Web App, API, or any feature of your App
Action – Read , Write, Delete, Approve, Deny, etc.
Is the User (Subject) allowed to Perform the said action on a Resource?

5. Seattle | September 16-17, 2019
Role Based Access Control – one form of AuthZ
Role
Resources
Actions
Group

6. Seattle | September 16-17, 2019
Developer’s view of Implementing RBAC
If Role == “Manager|Admin”
{
return True;
}
Something along those lines..
- Rules are hard coded in the code.
- Implementation varies between Teams / Stack

7. Seattle | September 16-17, 2019
Dev-Sec-Ops
Developer- Implements AuthZ logic
Security – wants to verify if you can enforce “need to know” basis / Least
privilege.
Ops – wants to make sure everything is running / deployment doesn’t take
hours, etc.

8. Seattle | September 16-17, 2019
When Security Team reviews the code/deployment?
Security: Can I change what this Role- Manager or Admin can do ?
Developer : ?? Why??
Security:
1. Our Policy
2. Its too high of privileges for Role- XYZ ( e.g. Manager)
3. Separation of Duties

9. Seattle | September 16-17, 2019
How would a Developer Re-design RBAC?
Role
Permission
Group
Permission
Resource+Action

10. Seattle | September 16-17, 2019
Back to Security
Security – Super Excited !!.. At least I was when I did this in 2004

11. Seattle | September 16-17, 2019
Operations – How to deploy this in Production?
On Call person who has to deploy/ debug Apps permissions have to
1. Add Resources / Permissions
2. Create new Roles
3. Map Roles to Permissions
Its usually 10’s of pages of doc per Application. 
Listen to talk about Security & Dev Ops by @IanColdwalter BSidesNOVA
2019
https://www.youtube.com/watch?time_continue=2&v=OlAFuiDCqbM

12. Seattle | September 16-17, 2019
Operations Person?
Imagine managing/configuring Roles, Permissions, Resources for multiple
apps

13. Seattle | September 16-17, 2019
Did Centralized AuthZ model work?
1. Hard coded apps to centralized authorization services
2. App developers have to understand AuthZ Service to better take
advantage of centralized service.
3. Changing permissions/policies is not easy
4. It actually slows down time to deploy.

14. Seattle | September 16-17, 2019
What If?
1. We externalize authorization from code
2. Provide developers full control of how they want to write their AuthZ
Rules
3. Give Security Teams option to customize the authZ rules/policies
4. Does not Involve too much operational overhead
5. Reduces time to deploy?
6. Consistent way to enforce policies across various languages/stack

15. Seattle | September 16-17, 2019
Intro to Open Policy Agent
Client/App- makes REST API call to get Decisions from OPA
OPA – makes Policy Decision – Evaluating Input Data against
Policies
OPA Policies are written in Rego outside of Code

16. Seattle | September 16-17, 2019
OPA and Rego
1. Rego is a query language
2. OPA Policies are written in Rego
3. SQL for Authorization – You write your AuthZ rules in a consistent
manner.

17. Seattle | September 16-17, 2019
OPA - Example Policy
package httpapi.authz
subordinates = {"alice": [], "charlie": [], "bob": ["alice"], "betty": ["charlie"]}
import input as http_api allow
{
http_api.method = "GET"
http_api.path = ["finance", “salary", username]
username = http_api.user
}

18. Seattle | September 16-17, 2019
OPA – Other benefits
• Provides an Interface to get Decision Logs through API / Web Hooks
• Provides an option to get Telemetry about OPA itself ( up /down)
• Policies can be distributed as Bundles ( Bundles = Rego file, Data file)

19. Seattle | September 16-17, 2019
OPA – Interactions from Developer Point of View

20. Seattle | September 16-17, 2019
Externalized Policy

21. Seattle | September 16-17, 2019
Kubernetes AuthZ model

22. Seattle | September 16-17, 2019
Key takeaways
• Externalize Authorization from your code – As product / Service
• During Security Reviews – ask If Authorization can be externalized from
code
• Use Open Policy Agent to standardize on how to write AuthZ rules.
• Integrate with SIEM for decisions- allow/deny.
• Establish a pattern across your Product/Service for consistent authZ.
Authorization does not happen without a proper Authentication.
Check out– SPIFFE /SPIRE for Secure Introduction of Identities

23. Seattle | September 16-17, 2019
Thank You.
@Lsitaraman