Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

Ignasi Barrera

November 18, 2021
Tweet

More Decks by Ignasi Barrera

Other Decks in Technology

Transcript

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

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

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

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

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

    2 EU SRE Jamie Bas EU US Location RBAC US Allowed
  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 Denied
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. For any further queries, feel free to contact us at

    [email protected] Contact Thank You @tetrateio Tetrate www.tetrate.io