Next-gen Authorization

The role of NGAC and Service Mesh for Enterprise-wide Authorization

Transcript

1. May 25, 2023 Next-gen Authorization The role of NGAC and Service Mesh for Enterprise-wide Authorization Ignasi Barrera, Founding Engineer, Tetrate Zack Butcher, Founding Engineer, Tetrate
2. 2 Agenda • Who we are • Introduction to NGAC • Overview of the Service Mesh • Mesh as NGAC PEP • Key takeaways
3. 3 Next Generation Access Control
4. 4 Next Generation Access Control 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
5. 5 Next Generation Access Control (NGAC) 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 NGAC has the flexibility of ABAC, but has a set of guardrails that keep it structured and understandable like RBAC.
6. 6 Why NGAC? Policy modeling capabilities • graph based • multiple classes of policy (eg RBAC, LBAC, DAC, domain) in the same decision • scalable in terms of user and object attributes • as expressive as ABAC: can model any XACML/ABAC policy
7. 7 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 Why NGAC?
8. 8 Why NGAC? Decision-time Performance • linear time evaluation algorithm ◦ roughly, O(|user attributes| + |object attributes| + |associations|) or, the size of the subgraph for the user and object in question • efficient (linear time) algorithms to produce ACLs ◦ have your cake and eat it too: optimal runtime enforcement and great policy introspection (see next slide)
9. 9 Why NGAC? Policy Review • Audit: 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.”
10. 10 NGAC Architecture NIST SP 800-204B: Attribute-based Access Control for Microservices-based Applications Using a Service Mesh
11. 11 The Service Mesh
12. 12 The Service Mesh is a dedicated infrastructure layer enabling you to monitor, secure, connect and manage services consistently. It can be used to implement Identity Based Segmentation at runtime, among other use cases.
13. 13 What’s a Service Mesh Deploy a sidecar proxy next to every application instance, which intercepts all traffic in and out to achieve: • L7 application identity & encryption in transit • Per request policy and controls • Service discovery, load balancing, and resiliency • Operational telemetry: metrics, logs, and traces And control them centrally with declarative configuration.
14. 14 Mesh Features • Service Discovery • Resiliency Retry, outlier detection, circuit breaking, timeouts, etc. • Load Balancing (Client side) • Fine-grained traffic control L7, not L4! Route by headers, destination or source, etc. • Policy on requests Authentication, rate limiting, arbitrary policy based on L7 metadata • Workload identity (L7) • Service-to-service authorization • Metrics, Logs, and Tracing
15. 15 Mesh Features • Service Discovery • Resiliency Retry, outlier detection, circuit breaking, timeouts, etc. • Load Balancing (Client side) • Fine-grained traffic control L7, not L4! Route by headers, destination or source, etc. • Policy on requests Authentication, rate limiting, arbitrary policy based on L7 metadata • Workload identity (L7) • Service-to-service authorization • Metrics, Logs, and Tracing • Consistency across the fleet • Centralized control • Ease of change
16. 16 Istio is the most widely used mesh. Envoy is its sidecar proxy.
17. 17 Istio lets us bound attacks in space and in time Runtime encryption, authentication, and authorization reduce the attack surface exposed that’s exposed by our applications. Like we saw earlier today, it can help us achieve runtime controls for a ZTA.
18. 18 App 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
19. 19 App Envoy is an NGAC Policy Enforcement Point We can use Envoy as the PEP in an NGAC deployment, with runtime decisions rendered by NGAC and enforced with the mesh sidecar. NIST SP 800-204B
20. 20 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
21. 21 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
22. info@tetrate.io @tetrateio Tetrate tetrate.io Thank You
23. 23 NGAC Architecture NIST SP 800-204B: Attribute-based Access Control for Microservices-based Applications Using a Service Mesh Pluggable: Mesh, eBPF, SDK, etc. NGAC Runtime