ISTIO WEEKLY #13 ACCESS CONTROL FOR MICROSERVICES 

Access Control at a glance Access control systems need to provide two fundamental use cases: ● Making access decisions ● Configure access policies 

Access control systems need to provide two fundamental use cases: ● Making access decisions check ( Principal, Operation, Resource ) = allow/deny ● Configure access policies Access Control at a glance Who What (Authenticated Principal) 

Access Control at a glance Access control systems need to provide two fundamental use cases: ● Making access decisions check ( Principal, Operation, Resource ) = allow/deny ● Configure access policies ○ Types of policy ■ Role based ■ Attribute based ■ Discretionary access ■ ... ○ Policy APIs ○ Policy language Who What (Authenticated Principal) 

Role Based Access Control (RBAC) ● Easy to understand ● Easy to author correct policy ● Brittle, hard to model everything (role explosion!) Access Control systems Attribute Based Access Control (ABAC) ● Hard to understand ● Hard to author correct policy ● (Infinitely) flexible, easy to model anything 

Access Control systems NGAC has the flexibility of ABAC, but has a set of guardrails that keep it structured and understandable. Role Based Access Control (RBAC) ● Easy to understand ● Easy to author correct policy ● Brittle, hard to model everything (role explosion!) Attribute Based Access Control (ABAC) ● Hard to understand ● Hard to author correct policy ● (Infinitely) flexible, easy to model anything 

Next Generation Access Control (NGAC) Developed by NIST ● By David Ferraiolo and team at NIST Works by closely modeling the system under control in a graph ● Model the Users and Objects in the system, and their relations, directly ● Policies you write create new relations (edges in the graph) ● Makes access control decisions by walking the graph Can compute a policy decision across many classes of policy in a single pass ● e.g. RBAC + Location + Time ○ “SRE team members can READ, WRITE the service” ○ “US employees cannot read data stored in the EU” ○ “contractors lose access after 3 months” Audit and Explain ● Why a policy decision was made, before or after the fact 

Example The following example shows a simple NGAC graph with: ● A User DAG representing an organization structure ● Object DAG representing files and folders in a filesystem, and a categorization of the files ● Two different policies - file system and scope - that can be combined to make access decisions. ● The association edges between the two DAGs define the permissions the actors have on the target resources. 

Why NGAC? ● Policy modeling capabilities ○ Graph based ○ Multiple classes of policy (eg RBAC, LBAC, DAC, ...) ○ Scalable in terms of user and object attributes ● Ease of Administration ● Decision-time Performance ● Policy Review 

Why NGAC? ● Policy modeling capabilities ● Ease of Administration ○ Administrative policies can be modeled directly in NGAC ○ Policies live in the same graph as user-policies ○ First-class delegation ■ Uniform access control over resources as well as admin data ■ We can write policy that governs federation ● Decision-time Performance ● Policy Review 

Why NGAC? ● Policy modeling capabilities ● Ease of Administration ● Decision-time Performance ○ Linear time evaluation algorithm ■ roughly, O(|user attributes| + |object attributes| + |associations|) ○ Efficient (linear time) algorithms to produce ACLs ● Policy Review 

Why NGAC? ● Policy modeling capabilities ● Ease of Administration ● Decision-time Performance ● Policy Review ○ Audit (incl. “before the fact”): see what resources are (will be) affected by a policy ○ Explain: understand why a particular access was allowed, in human-readable terms; eg: ■ “Nic was allowed access because: ● He is a member of group A which has RBAC policy B (authored by Zack on Sep 1, 2021) granting permissions X,Y,Z on container C, which contains the target resource Foo ● He is a member of group F which was granted a location based policy G (authored by Varun on August 27, 2021) which grants permission X on container H, which contains the target resource Foo ● Only location and RBAC policies applied, therefore Nic is able to take action X on target resource Foo.” 

NGAC Deep Dive NGAC 

NGAC Architecture PEP- Policy Enforcement Point PDP - Policy Decision Point EPP - Event Processing Point PAP - Policy Administration Point PIP - Policy Information Point RAP - Resource Access Point 

NGAC Architecture 1. A process attempts to gain access to a resource via a PEP 2. The PEP issues an access request to a PDP for adjudication 3. The PDP queries the PAP for policy information needed to compute an access decision 4. The PAP issues the requisite commands to the PIP to retrieve the information 5. The PAP returns the queried information to the PDP; 6. The PDP renders a decision on the access request, resolves the resource location (only for a positive decision), and returns the decision and locator to the PEP; 7. The PEP issues a directive to the RAP associated with the resource to carry out the access; 8. The RAP carries out the operation on the resource and receives the status information and result data (if any); 9. Status information and data (if any) are returned from the RAP to the PEP; and 10. Status information and data (if any) are returned from the PEP to the process. 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US Policy Classes User Attributes Users Object Attributes Objects Associations 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US 

RBAC NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 Jamie Bas SRE 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU Jamie Bas EU US Location US 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US Allowed 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US 

NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance 2 EU SRE Jamie Bas EU US Location RBAC US Denied 

Benefits and Use cases Benefits ○ Single Policy framework for Organization ○ Capabilities: ABAC, LBAC, RBAC -- all into one Use cases ○ Can compute a policy decision across many classes of policy in a single pass ○ e.g. RBAC + Labels + Location + Time ■ User X with clearance Y can view data from streaming service ■ User X from US Eng, can access table X and row Y ■ User X above a rank from US Eng can access the folder but not a specific file 

Access Control at Scale 

A Service Mesh enables cross- cutting change A mesh allows for centralized control with distributed enforcement. Central teams can manage policy on behalf of the org. NIST SP 800-204A 

The Mesh forms a Security Kernel With Envoy as PEP we can move security concerns out of the application and into the mesh. NIST SP 800-204B 

Envoy is a universal Policy Enforcement Point Envoy intercepts all traffic and can apply policies at the application layer. It is a reference monitor. NIST SP 800-204B 

NGAC Architecture PEP- Policy Enforcement Point PDP - Policy Decision Point EPP - Event Processing Point PAP - Policy Administration Point PIP - Policy Information Point RAP - Resource Access Point 

NGAC in Production Today NGAC 

Collaboration with NIST ● CRADA for the application of Next Generation Access Control (NGAC) ○ as well as NDAC (NGAC over Database Queries) ○ INCITS 499-2018 ● Collaboration on Microservice Security Standards (SP800-204 series) ○ SP800-204A: Building Secure Microservices-based Applications Using Service-Mesh Architecture ○ SP800-204B (public draft): Attribute-based Access Control for Microservices-based Applications using a Service Mesh ○ SP800-204C (upcoming): Application of DevSecOps using a Service Mesh in Microservices-based Infrastructure ● Co-hosted conferences with NIST: ○ Jan 2020: Identity Management & Access Control in Multiclouds Workshop and Conference ○ Jan 2021: DevSecOps and Zero Trust Architecture (ZTA) for Multi-Cloud Environments 

TSB - NGAC in production now ● Tetrate Service Bridge (TSB) is the PIP, NGAC the PDP, and Envoy the PEP ● Tetrate Service Bridge uses NGAC to enforce user access to service mesh config and operations ○ Imports data from existing identity providers (LDAP, AD) ○ Unifies user data with observed runtime services and workloads ○ Enforces user access to TSB with Envoy PEP, per NIST SP 800-204B, with RBAC and time based APIs ● Will use NGAC to implement service-to-service authz by EOY ○ Gain benefits of NGAC’s audit and explain ○ Implement runtime enforcement via existing Envoy filters 

For any further queries, feel free to contact us at [email protected] Contact Thank You @tetrateio Tetrate www.tetrate.io