A Kubernetes Zero Trust Security Model Using a KMS Provider Plugin
summary
Kubernetes Secrets and ConfigMaps become encrypted in etcd by a tiny Go KMS provider plugin, trousseau.io, that sits next to the API server and forwards payloads to Vault Transit for encryption before storage, preserving native Kubernetes KMS-provider metadata. Authentication uses a Kubernetes service account, RBAC, Vault tokens and policies obtained via a Vault Agent init container, enabling centralized auth, per-component least privilege and audit logs; OpenShift is not supported, it’s open source and running in production on several distributions as a drop-in KMS provider. trousseau.io KMS provider
AI-written summary · about
chapters (10)
- 0:00Introduction and context
- 2:26Kubernetes security issues
- 3:18Zero trust principles
- 4:21Role of HashiCorp Vault
- 4:55The problem with K8s secrets
- 7:23Encryption at rest solution
- 8:08Introducing Truso
- 11:25Implementing zero trust
- 13:49Conclusion and auditing
- 14:20Roadmap and future work
related talks
31mVault and Secret Management in Kubernetes
39mManaging and securing Kubernetes secrets - Simon Pearce
20mEvolving Kubernetes security with Vault and OpenShift
42mZero Trust security with HashiCorp Vault and AWS (PRT239)
29mHow to Make Kubernetes Secrets Really… Secret?
01h 03mSecuring Legacy Applications and Container Microservices in Kubernetes
35mTurtles All the Way Down: Managing Kubernetes Secrets
54mKeeping Kubernetes secrets secret