• Making access decisions check ( Principal, Operation, Resource ) = allow/deny • Configure access policies Access Control at a glance Who What (Authenticated Principal)
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)
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
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
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
• 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.
Multiple classes of policy (eg RBAC, LBAC, DAC, ...) ◦ Scalable in terms of user and object attributes • Ease of Administration • Decision-time Performance • Policy Review
◦ 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
• 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.”
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.
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
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) 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
nacx
akuwano
uhyo
o11yfes2023
masakiokuda
yunosukey
fumisuke
tacck
lambda
p0deje
non97
duelist2020jp
msyksphinz
chriscoyier
trallard
tanoku
hatefulcrawdad
vanstee
iamctodd
afnizarnur
skipperchong
samlambert
brad_frost
kevinliebholz
rocio
