logo

Untangling the Multi-Cloud Identity and Access Problem With SPIFFE Tornjak

2021-10-14

Authors:   Brandon Lum, Mariusz Sabath


Summary

The presentation discusses the Universal Zero Trust Workload Identity project, which aims to strengthen security by executing cloud provider-specific and platform attestation, and supports different identity mechanisms using consistent universal identity schema.
  • The Universal Zero Trust Workload Identity project aims to strengthen security by executing cloud provider-specific and platform attestation.
  • It supports different identity mechanisms using consistent universal identity schema.
  • The project uses Kubernetes and can be deployed on any cloud provider.
  • The project is still in development and is open to feedback and contributions.
  • The presentation includes a demo of the project using AWS and Vault to retrieve secrets.
  • The project has Helm charts and YouTube videos available for deployment and learning.
The demo showed how easy it is to get identities in one place from multiple clusters and clouds, and how one policy can allow access enforcement for several dynamically created workloads.

Abstract

When an organization moves to a multi-cloud environment, one of the first questions a developer will ask is “How do I access my S3 bucket in AWS from my GCP cluster?” (or any other permutations thereof cloud services/providers). This is an unsurprising request. However, the solutions to these problems today are surprisingly inadequate, especially when security and compliance are considered. This problem stems from cloud providers/services each having their own notion of workload identity and schema, which makes federation difficult. This talk proposes a shift in the perspective of workload identity from being “platform specific” to “organization wide” using SPIFFE/SPIRE and the new SPIFFE Tornjak project to provide a consistent and secure organization-wide management plane for workload identity and access across multiple clouds. After all, user identities are managed on the organization level (e.g. LDAP, etc.), why should our handling of workload identities be any different?

Materials: