This work is part of the open source testbed setup for Cloud interoperability & portability. Cloud Security Workgroup will further review and generate complete working set as we move along. This is part I of the effort.
1. CCICI
Cloud Interoperability 1.0 Testbed
Security Access Implementation & References
A presentation by
Krishna Kumar & Chengappa Munjandira
May 2021
2. Cloud Interoperability & Portability
Report 1.0 based
TestBed Setup
If you likes to be part of this open source project, join here
1) https://www.linkedin.com/groups/8247749/
2) https://ccici.in/
3. Cloud InterOp TestBed Architecture Framework
Cloud Provider Resources
(Compute, Network, Storage, etc.)
Infrastructure as Code
(Tosca, Terraform, Docker, Openstack, etc.)
Application / Services
(k8s, Compose, Vault, Consul, ServiceBrokers, etc.)
Data Access Layer
(CSI, SODA, VirtualDB, VirtualFS, etc.)
Security
&
Compliance
Monitoring
&
Logging
App/Service
Management
Data
Management
Network
Management
Standards
for
India
Cloud
End Users (ISP, SMBs, Startups, Incubators, Government Agencies, Universities)
vendor
Neutral
4. Authentication Flow - service to service across clouds
Cloud1
Service1
Cloud2
Service2
Zero trust network
1
2
The Operations flow legends:
1. Service1 initiate Service2/Cloud2
2. Cloud1 request OAuth Token from
Cloud2 (See the format of request)
3. Cloud2 process Token for specific
service with access and token
expiration
4. Cloud2 send Token back to Cloud1
5. Service1 call Service2 with access
token
6. Service1 consume Service2 action
(e.g: storage.objectread)
7. Service2 ACK/ERROR on call and
log the entries in Cloud2 logs
8. Service1 stop the service2 call as
needed by the operation
9. Cloud2 access Token expire
10. Service1 continue further operation
UR1. IUR
Token Request Format
1. Provider URI
2. Service Account
3. Account Key
4. Action*
5. Token expiration
InterOp Format
*Action Format
● compute.*
● network.*
● storage.*
● operations.*
3
4
5 6
7
8
5. Multi cloud Authentication & Authorization for Service provisioning
User /
Agent
Cloud 1:
Id Provider
Cloud 1:
Service Consumer
Zero Trust Tunnel
Cloud 2:
Id Provider 2
Cloud 2:
Service Provider
Connect to Cloud
Authentication : Access Token
Request Service Roll
Request Service mapping
Authorization Bearer Token
Authorized: Access Grants
Broker
Agent
Broker
Agent
Discovery
Selection
Monitoring
JWT:
valid?
expired?
Cloud Actor
Access
flow
1
Access flow 1
Cloud Auditor
Service
Templates
Service
provisioning
workflow
6. Authentication & Authorization OPTIONS:
The following will be in place:
1. Single Sign-On & Cloud Federated Identity prefered by the Organization, like Microsoft AD.
2. Multi-Factor Authentication with app/otp generated approval to avoid phishing attacks:
3. Legacy system IAM using solutions Security Assertion Markup Language (SAML) 2.0 Identity Provider (IdP)
4. Third party Identity service Identity-Management-as-a-Service (IDaaS) like OKTA
5. If you want to allow anonymous users access (quite common for eCommerce applications) to any part of our
application then you need to determine if you will be redirecting right away or prompting your users to redirect only
when required.
6. Auth0 Universal Login - the so-called Bring Your Own Identity scenarios provided via Social Login.
a. OpenID Connect & OAuth2.0
OAuth 2.0 is a framework that controls authorization, is a authorization protocol(OAuth only authorizes devices, API, servers with
access tokens rather than credentials and it works over HTTPS.); OpenID Connect and SAML are both industry standards for
federated authentication; OpenID Connect uses OAuth2.0 & JWT - mainly in websites and mobile (allows for ‘Federated
Authentication’); SAML - OAuth with XML format - mainly in enterprise user login in multiple apps. SAML is used for both
authentication & authorization between two parties;
https://medium.com/@jad.karaki/identity-management-saml-vs-oauth2-vs-openid-connect-c9a06548b4c5
7.
8. Standards/Benchmark Applicable
1. CIS benchmark - (e.g: kubernetes, cloud service providers, etc.)
2. Payment Card Industry Data Security Standard 3.2.1 (PCI-DSS v3.2.1)
3. OWASP Top Ten (OWASP - A1:A10)
4. National Institute of Standards and Technology 800-53 (NIST 800-53)
5. International Organization for Standardization ISO 27001/17/18
6. FIPS 140-2 standards
7. Cloud Security Alliances (CSA)
8. Cloud Computing Compliance Criteria Catalogue (CS:2020)
9. SOC for service Organizations - (AICPA SOC)
10. Refer:
a. AWS Compliance Programs - https://aws.amazon.com/compliance/programs/
b. Azure Compliance Offerings - https://docs.microsoft.com/en-us/azure/compliance/
c. Google Cloud Compliance Resource - https://cloud.google.com/security/compliance
9. Open solutions available for Cloud Interop
1. Crossplane - Manage any infrastructure your applications need directly from Kubernetes - https://crossplane.io/
2. Liqo - project that dynamically creates a big cluster - https://github.com/liqotech/liqo
3. Kubefed - coordinate the configuration of multiple Kubernetes clusters from a single set of APIs in a hosting cluster -
https://github.com/kubernetes-sigs/kubefed
4. Konveyor - help modernize/migrate applications - forklift(to KubeVirt), pelorus, windup - https://konveyor.io/
5. KubeVirt - virtuaization APIs for k8s - https://kubevirt.io/
6. oVirt - Virtualization with kvm hypervisor - https://www.ovirt.org/
7. Thanos - Prometheus at scale - https://thanos.io/
8. Open Data Initiative - a platform for a single, comprehensive view of your data -
https://www.microsoft.com/en-us/open-data-initiative
9. OAM model - runtime-agnostic specification that defines cloud native apps - https://oam.dev/
10. CloudARK - framework to offer platform services as-Code - https://cloudark.io/
11. KubePlus - CRD for CRDs for platform services - https://github.com/cloud-ark/kubeplus
12. Cloud Custodian - Cloud Security, Governance, and Management - https://cloudcustodian.io/
13. Edge - Akri, OpenYurt, OpenNESS, k3s, kubeedge
14. Storage - Ceph, EdgeFS, Rook, ChubaoFS, Longhorn, OpenEBS
15. Runtime - CRI-O, CSI, CNI
16. CNCF Projects - https://www.cncf.io/ & case studies https://www.cncf.io/case-studies/
17. Apache project list - https://www.apache.org/
10. TOP Announcements from Major Cloud Vendors in last 1+yrs:
● AWS re:invent
○ - https://aws.amazon.com/blogs/aws/aws-reinvent-announcements-2020/
● MicroSoft Build -
○ https://www.cloudwithchris.com/blog/build-2021-summary/
○ https://www.cnbc.com/2020/05/22/microsoft-build-2020-recap-windows-azure-and-teams-tools.html
● Google Cloud Next -
○ https://www.cnet.com/news/google-io-2021-every-announcement-developers-conference/
○ https://cloud.google.com/blog/topics/google-cloud-next/complete-list-of-announcements-from-google-cloud-next20-onair
● IBM Think -
○ https://www.ibm.com/cloud/blog/ibm-think-2021-key-announcements
○ https://www.eweek.com/innovation/ibm-think-2020-digital-building-reliability-resiliency-in-uncertain-times
● Oracle World -
○ https://www.forbes.com/sites/oracle/2019/09/25/larry-ellison-at-oracle-openworld-5-highlights-from-oracles-leader/?sh=22
1998582670
● VMWorld -
○ https://www.vmware.com/company/news/updates/2020/vmworld-2020-news-announcement-summary.html
● Alibaba Apsara -
○ https://www.cloudmanagementinsider.com/alibaba-cloud-enters-next-phase-with-cloud-2-0-new-cloud-os-first-cloud-comp
uter/
Look for latest on interoperability / Hybrid cloud solutions...
12. OAuth2 Flow Diagram Get Access Token flow has 5
steps (as shown in the diagram):
1. Pre-register Client (App)
with OAuth Server to get
Client ID/Client Secret
2. OAuth Server
authenticates user when
she clicks on the App’s
social login button, which
is tagged with Client ID
3. OAuth Server solicits user
permission to allow the
App to perform something
on her behalf
4. OAuth Server sends secret
Code to App
5. App acquires Key/Access
Token from OAuth Server
by presenting secret Code
and Client Secret
https://blog.oauth.io/introduction-oauth
2-flow-diagrams/
13. BANZAI CLOUD - Zero Touch Authentication Flow This is how the whole flow looks:
1. The user uses the Backyards CLI to perform a
Backyards command.
2. The Backyards CLI creates a proxy endpoint to reach
the Backyards service (we call it the “Server” from
here on in), on a local port.
3. The Backyards CLI uses client-go to create an HTTP
Transport that will automatically authenticate
against the auth provider and will add a valid Bearer
token to every request, except when Client
Certificates are being used. In the event that Client
Certificates are being used, the CLI will simply add
the Client Certificates to the login request’s body.
4. The Backyards CLI calls the login API on the Server.
5. The Server verifies Bearer Tokens using the
TokenReview API (or the Server verifies Client
Certificates through a separate client)
6. The Server also uses the SubjectAccessReview API to
get information about the user’s capabilities.
7. The Server issues a JWT, encoding all the user’s
groups and capabilities with a longer expiration (10h),
and wraps it in an encrypted JWE with a shorter
expiration (5s).
8. The Backyards CLI receives the tokens, and can
cache and work with the JWT for as long as it’s valid.
9. If the user calls the dashboard command, then the
Backyards CLI has to use the encrypted JWE to open
the browser tab.
https://banzaicloud.com/blog/zero-touch-authentica
tion-on-kubernetes/