Save 37% off PRO during our Black Friday Sale! »

Access Control for Microservices

Access Control for Microservices

In this episode of Istio weekly, I talk about access control for microservices and explain what NGAC is and why it matters to you.

4ca6230b05046f1a809835985b1f8bc2?s=128

Ignasi Barrera

November 18, 2021
Tweet

Transcript

  1. ISTIO WEEKLY #13 ACCESS CONTROL FOR MICROSERVICES

  2. Access Control at a glance Access control systems need to

    provide two fundamental use cases: • Making access decisions • Configure access policies
  3. 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)
  4. 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)
  5. 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
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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
  11. 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
  12. 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.”
  13. NGAC Deep Dive NGAC

  14. 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
  15. 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.
  16. NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance

    2 EU SRE Jamie Bas EU US Location RBAC US
  17. 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
  18. NGAC Deep Dive: Inside the PDP frontend Instance 1 Instance

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

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

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

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

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

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

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

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

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

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

    2 EU SRE Jamie Bas EU US Location RBAC US Denied
  29. 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
  30. Access Control at Scale

  31. 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
  32. 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
  33. 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
  34. 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
  35. NGAC in Production Today NGAC

  36. 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
  37. 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
  38. For any further queries, feel free to contact us at

    info@tetrate.io Contact Thank You @tetrateio Tetrate www.tetrate.io