CNSCon 2024 Lightning Talk: Don’t Make Me Impersonate My Identity

Identities are a crucial part of running workloads on Kubernetes. How do you ensure Pods can securely access Cloud resources? In this lightning talk, you will learn how large Cloud providers work together to share Identity Provider responsibilities in order to federate identities in multi-cloud environments.

1. Don’t Make
Me
Impersonate
My Identity
Lightning Talk
Cynthia Thomas
linkedin.com/in/cynthia-thomas, @_techcet_
GKE Security, Google Cloud

2. Kubernetes Pods and their identities
-In Kubernetes, Pods are given a distinct identity
within a Kubernetes cluster

-How? Through a Service Account: typically an
account type for non-humans

-Pods are always given Service Accounts by default or
configured

3. How to get Pods to talk to Cloud Resources
Options:
1.Export credentials and mount as a Kubernetes
secret in the Pod at runtime

2.Use the worker node/VM identity credential

3.Use Workload Identity Federation

4. Cloud provider K8s Cluster
K8s Worker Nodes

K8s Worker Nodes

K8s Worker Nodes
Namespace foo

Pod


Pod

K8s Control Plane

kube-API server
Workload Identity Federation at work
Step 2: Secured
communication
Cloud IAM
Cloud API
Step 1: Trust
Established
Blog: Kubernetes token support for OIDC

5. Before After
Create Kubernetes namespace Create Kubernetes namespace
Create Kubernetes Service Account
(KSA)
Create Kubernetes Service Account
(KSA)
Create Google Service Account Not needed
Configure KSA to impersonate GSANot needed
Annotate KSA with the GSA so GKE
knows the link
Not needed
Bind role to Google Service Account
(GSA)
Bind role directly to KSA

SA
Impersonation
Just say no to impersonation

6. -Dont worry about managing secrets



-Dont worry about identity impersonation

-Federate identities - supports OIDC/SAML and now X.509
certificates with SPIFFE
Don’t make me impersonate my identity
Be more secure with Workload Identity Federation!