Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Authorization for workloads in a dynamically scaling heterogeneous system


Published on

Defines a design based on SPIFFE and OPA standards to address authorization between workloads residing in multiple clouds and interacting with each other.

Published in: Software
  • Be the first to like this

Authorization for workloads in a dynamically scaling heterogeneous system

  1. 1. FABRIKAM AUTHORIZATION FOR WORKLOADS IN A DYNAMICALLY SCALING HETEROGENEOUS SYSTEM M.K.P.R. Jayawardhana 158217G Supervised by Prof. Gihan Dias Mr. Prabath Siriwardena Master of Science in Computer Science and Engineering University of Moratuwa Sri Lanka
  2. 2. Dvaara Contribution of the Research Considering ‘Cloud’(eg: Amazon EC2, Azure, GCP) as the most common use case of a dynamically scaling, heterogeneous system, ● Design a solution for authorization among multi-cloud systems ● Implement the designed solution Re-use + implement lacking components + integration ● Implementation evaluation using a case study ● Performance evaluation 2
  3. 3. Dvaara 3 Introduction Ref : 3 Modern Enterprise Systems, ● Mostly Distributed Systems ● Horizontal Scaling ● Avoid vendor lock-in ● Make use of external systems than having everything in-house, ○ Make use of SaaS providers ○ Make use of PaaS providers ○ Make use of IaaS providers ● High availability concerns ● Elasticity of the system is a concern with rapid growth and peak and off-peak times. ● Follows Micro Services Architecture(MSA)
  4. 4. Dvaara Why multi-cloud? ● Organizations are concerned on moving everything to the cloud → Security and Privacy concerns + Vendor lock-in ● Hybrid cloud to get started → Sensitive data residing on-premise and heavy computing delegated to an external cloud. ● Cost-effectiveness and reducing go-to-market time makes cloud appealing. Introduction 4 Ref:, “MSA(Microservice Architecture)-specific IAM(Identity and Access Management) is still in its infancy. The primary focus of the MSA community thus far has been authentication and, more narrowly, the use of OAuth 2.0, leaving other important questions, such as the authorization architecture, unaddressed”?? - Gartner
  5. 5. Dvaara Problem Problem Statement ● Enterprise systems are becoming a service mesh. ● Each component of the system needs to scale as required, while being able to interact with other services. ● Interaction needs to be secured. ● Authentication between these services is being addressed. 5Ref : How do we define and implement an authorization system for a multi-cloud enterprise system?
  6. 6. Dvaara Use Case Problem Statement An e-commerce company has decided to start a cloud journey with below, considering the features supported by each CSP, cost and vendor lock-in. ● Keep the sensitive business operations in the on-premise cloud. ● Send data to be stored or archived to Amazon S3. Use EC2 analyse and summarize this data. ● Host a dashboard in GCP, that summarizes the details in Amazon S3 to identify the trends in the market. ● Need high elasticity (peak, off-peak seasons and times) To build the secure boundary, below interactions need to be secured - On-premise to Amazon - Amazon to GCP 6
  7. 7. Dvaara Use Case - Problem Problem Statement Service authentication between multi-clouds when dynamic scaling is in place, is already a concern being addressed by research community. - Shared secret based - Kerberos protocol - CSP provided privileged API - SPIFFE standard How to support ‘Service Authorization’ in this system? 7 What should he be allowed to do?
  8. 8. Dvaara Approach ● Study existing models, solutions and standards that support authorization between services. ● Study the other relevant aspects of authorization such as authentication and administration of access control policy as required by the authorization architecture for a cloud system. ● Build up the components of the architecture, that can coexist with the current enterprise systems, providing authorization capabilities across clouds. 8 Objectives
  9. 9. Dvaara Literature Review Literature Review 1. Classical Security Models 1.1. Authentication 1.2. Authorization 2. Future of Cloud Systems 3. Workloads 3.1. Workload Authentication 3.2. Workload Authorization 9
  10. 10. Dvaara Access Control Literature Review 10 Ref : R. S. Sandhu and P. Samarati, “Access control: principle and practice,” IEEE Commun. Mag., vol. 32, no. 9, pp. 40–48, 1994
  11. 11. Dvaara Authentication Literature Review Identifying an entity such as a person, a group, a device or an application to be what they declare to be, - Something Known - Something Possessed - Something Inherent 11 Ref: D. Gollmann, “Computer security,” WIREs Comp Stat, vol. 2, no. 5, Sep. 2010
  12. 12. Dvaara Authorization Literature Review ● DAC ● MAC ● Access Control Matrix ○ Access Control List ● RBAC ● ABAC ● XACML ● OPA 12 Image : 95/top-ten-reasons-why-developers-dont-adopt-abac-10-638.jpg Ref : R. S. Sandhu and P. Samarati, “Access control: principle and practice,” IEEE Commun. Mag., vol. 32, no. 9, pp. 40–48, 1994
  13. 13. Dvaara Classical Security Models Literature Review ● Bell-La-Padula model - Confidentiality ● BIBA model - Integrity ● Chinese-Wall model - Conflict of Interest ● Clark-Wilson model - Integrity of commercial systems, Separation of duties ● Graham-Denning(GD) model - State transitions based on ACM ● Harrizon-Ruzzo-Ullman Model - Extending GD model ● Take-Grant Model - State transitions for confidentiality 13 Ref: D. Gollmann, “Computer security,” WIREs Comp Stat, vol. 2, no. 5, Sep. 2010
  14. 14. Dvaara Cloud Literature Review - The most common, dynamically scaling, heterogeneous system - SaaS, PaaS, IaaS - Hyper-converged cloud to catalyze multi-cloud systems 14Ref:
  15. 15. Dvaara Workload Literature Review “A highly cohesive and de-coupled capability or a unit of work that collectively builds up an enterprise application, which can be running on cloud or on-premise” Eg: ● a microservice ● a Kubernetes pod ● a process in a VM 15 Ref: Ref : M. C. Calzarossa, M. L. Della Vedova, L. Massari, D. Petcu, M. I. M. Tabash, and D. Tessera, “Workloads in the Clouds,”, Springer International Publishing, 2016, pp. 525–550
  16. 16. Dvaara Workload Authentication Literature Review ● Challenge-response authentication ○ Credentials stored with workload ○ Challenged to provide an inherent attribute based on the system ● Needham–Schroeder protocol ○ Use a symmetric key ○ Based on a third party ‘Authentication server’, building trust ● Kerberos Protocol ○ Based on KDC (Key Distribution Center) ○ Not relying on network security 16 Ref: B. C. Neuman and T. Ts’o, “Kerberos: an authentication service for computer networks,” IEEE Commun. Mag., vol. 32, no. 9, pp. 33–38, Sep. 1994.
  17. 17. Dvaara Single Cloud Authentication Literature Review ● Platform provided privileged API based authentication ○ Amazon EC2 IID ○ Google Cloud Provider IIT ○ Microsoft Azure MSI 17 { "iss": "[TOKEN_ISSUER]", "iat": [ISSUED_TIME], "exp": [EXPIRED_TIME], "aud": "[AUDIENCE]", "sub": "[SUBJECT]", "azp": "[AUTHORIZED_PARTY]", "google": { "compute_engine": { "project_id": "[PROJECT_ID]", "project_number": [PROJECT_NUMBER], "zone": "[ZONE]", "instance_id": [INSTANCE_ID], "instance_name": "[INSTANCE_NAME]" "instance_creation_timestamp": [CREATION_TIMESTAMP] } } }
  18. 18. Dvaara Multi-Cloud Authentication Literature Review SPIFFE (Secure Production Identity Framework For Everyone) ● A common protocol based on ‘Platform Provided Privileged API’ for authentication. ● Extendable to work with CSPs. ● A standard accepted by the CNCF(Cloud Native Computing Foundation). 18
  19. 19. Dvaara Workload Authorization Literature Review ● RBAC ○ OAuth 2.0 with scopes - client_credentials grant ● ABAC ○ OAuth 2.0 with scopes - client_credentials grant ○ XACML ○ OPA ● Authorization Servers in the market ○ Based on OAuth2.0 MTLS standard ○ KeyCloak, Gluu, WSO2 IS, Ping Identity, IBM API Connect 19
  20. 20. Dvaara Solution Design 20
  21. 21. Dvaara Dvaara Design Options Solution Design Enforcing authentication and authorization 21 Local authentication and authorization Local authorization and Global authentication Local authentication and Global Authorization Global authentication and authorization
  22. 22. Dvaara Dvaara Design Authentication Solution Design Comparison Authentication Mechanism 22 Mechanism Do not require to deploy credentials with the workload Single identity per workload API driven credentials rotation and distribution Cross-platform trust building Firewall Yes Yes No Yes Destination authentication No No No Yes Platform mediated identity Yes Yes Yes No SPIFFE Yes Yes Yes Yes
  23. 23. Dvaara Dvaara Design Authorization Solution Design ● DAC vs MAC ○ Governing authorization of information flow is not in the current scope ○ Hence DAC ● RBAC vs ABAC ○ Need to considered fine grained attributes of workloads 23 RBAC ABAC Simplicity Yes Can be Complex Fine-grained No Yes Standardized No Yes (XACML/OPA) Comparison Authorization Mechanism
  24. 24. Dvaara Dvaara Design - XACML or OPA Solution Design ● XACML vs OPA - policy comparison 24 XACML OPA Flexible ABAC support Yes Yes Extendability Yes Yes Complexity High Occasionally Verbose Yes No Required training Yes (Though it’s XML, have specific functions and behaviors to understand) Yes (Though it’s JSON like, have special meanings for symbols and ways of writing rules) Implementation Availability Axiomatics, Sun XACML engine, WSO2 Identity Server OPA Background Open standard by OASIS Open implementation, CNCF accepted.
  25. 25. Dvaara Overall Design 25 Solution Design
  26. 26. Dvaara Dvaara Architecture Solution Design 26
  27. 27. Dvaara Dvaara Implementation Solution Implementation 27
  28. 28. Dvaara Dvaara Implementation Ctd Solution Implementation 28
  29. 29. Dvaara Dvaara Implementation Contribution Solution Implementation Chain of Responsibility Pattern 29 TLS level validation on the SPIFFE X509 cert OPA based decision on allowed scopes, based on SPIFFE ID Token validation request ABAC, validating the workload attributes and context against OPA policy Using Java-SPIFFE lib New implementation of OPA based scope validation handler New implementation of OPA based token validation handler - Selected WSO2 IS authorization server was patched to support required parameters to be sent to OPA engine. WSO2 IS patched to enrich
  30. 30. Dvaara Evaluation Solution Evaluation 30 1 2 1 - Token Request 2 - Actual API consumption using token
  31. 31. Dvaara Demo 31
  32. 32. Dvaara Evaluation Solution Evaluation 32 Correctness - Considered the use case of an employee management solution - Authorized access to a salary mgt API - Fine grained authorization based on Infrastructure layer details and application layer details - Verified results against the expected results
  33. 33. Dvaara Conclusion 33 - What Dvaara can do? - Make authorization decisions based on infrastructure level and application level attributes - Understands the SPIFFE based authentication - Allow dynamic changes to authorization policy - Dvaara provides a viable solution for workload authorization in a multi-cloud system - Dvaara provides fine grained authorization in a dynamic manner - Dvaara bridges the existing authorization technology of OAuth 2.0 and TLS widely adopted open standard to the emerging cloud native standards of SPIFFE and OPA - Dvaara open doors for the existing enterprise systems to have benefits of hybrid or multi-cloud without compromising on service authorization policies.
  34. 34. Dvaara Future Work 34 - Make access token a JWT(JSON Web Token) that can carry attributes(advices) between the workloads - Federation between SPIRE server or Authorization servers to expand trust boundary in a seamless manner - Performance improvements - add caching improvements at token validation - Provide an administration portal for the system - Single view on policy available to issue SPIFFE IDs - Single view of policies active in OPA engine - CRUD operations on the policies and evaluating the effect - Current overview of the system (active workloads, tokens etc.) - OAuth 2.0 specification to bind the token to the TLS layer. (currently happening in Dvaara in an indirect way)
  35. 35. FABRIKAM THANK YOU Pushpalanka 35