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

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. 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. Dvaara
3
Introduction
Ref : https://www.slideshare.net/ajessup/building-trust-between-modern-distributed-systems-with-spiffe
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. 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:
https://www.nutanix.com/enterprise-cloud-index/docs/enterprise-cloud-index.pdf,
https://www.gartner.com/doc/3784664/building-identity-microservices
“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. 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 : https://azure.microsoft.com/en-us/blog/microservices-on-azure-kubernetes-guidance/
How do we define and implement an authorization system
for a multi-cloud enterprise system?

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. 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. 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. 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. 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. 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. Dvaara
Authorization
Literature Review
● DAC
● MAC
● Access Control Matrix
○ Access Control List
● RBAC
● ABAC
● XACML
● OPA
12
Image :
https://image.slidesharecdn.com/350pmaxio-irmsummit2014gerry-140611105654-phpapp02/
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. 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. Dvaara
Cloud
Literature Review
- The most common, dynamically scaling, heterogeneous system
- SaaS, PaaS, IaaS
- Hyper-converged cloud to catalyze multi-cloud systems
14Ref: https://www.timetoast.com/timelines/cloud-computing-history

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: https://siliconangle.com/wp-content/blogs.dir/1/files/2016/02/illumio.png
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. 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. 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. 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. 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. Dvaara
Solution Design
20

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. 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. 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. 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. Dvaara
Overall Design
25
Solution Design

26. Dvaara
Dvaara Architecture
Solution Design
26

27. Dvaara
Dvaara Implementation
Solution Implementation
27

28. Dvaara
Dvaara Implementation Ctd
Solution Implementation
28

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. Dvaara
Evaluation
Solution Evaluation
30
1
2
1 - Token Request
2 - Actual API consumption using token

31. Dvaara
Demo
31

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. 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. 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. FABRIKAM
THANK YOU
https://medium.com/@Pushpalanka
https://github.com/Dvaara/
Pushpalanka
pushpalankajaya@gmail.com
35