-
Notifications
You must be signed in to change notification settings - Fork 11
Home
The 5-minute read about Trousseau
- What is Trousseau?
- What is Trousseau for?
- What does Trousseau solve?
- What are Trousseau's design principles?
- How does Trousseau accomplish its goals?
Trousseau is an open-source project leveraging the Kubernetes Key Management Service (KMS) provider framework to secure Secrets within the Kubernetes etcd instance using the concept of Transit Key stored within a remote KMS.
Trousseau deploys as a DaemonSet and does not require additional skills or toolings as it is native to the Kubernetes Secret API object and the KMS provider plugin framework.
Trousseau is designed to connect the Kubernetes kube-apiserver with a remote KMS to encrypt the Secret payload before saving it within the Kubernetes etcd. Trousseau is used by customers for test up to production-grade environments.
By using Trousseau, the user will address the following flaws:
- Zero Trust environment
- Kubernetes Secrets are insecure by design as the payload saved in etcd is encoded in base64. Anyone having access to kubectl and the related namespace can read the content of the secrets.
- Third party solutions includes the usage of additional skill and tools slowing down adoption and integration within existing pipeline or GitOps practices.
- Third party solutions are not providing support for native Kubernetes Secret API object usage which is used by low level and critical components of Kubernetes like controllers, CNI, CSI, ...
- zero trust security model
- develop in Golang
- respectful of Kubernetes native API and the Kubernetes KMS provider plugin framework
- integrate with multiple KMS provider solutions
- integrate with 3rd party like SOPS
Here is the quote from the Kubernetes KMS provider page defining the design and architecture principles that Trousseau (referred as KMS plugin) is based on:
The KMS encryption provider uses an envelope encryption scheme to encrypt data in etcd. The data is encrypted using a data encryption key (DEK); a new DEK is generated for each encryption.
The DEKs are encrypted with a key encryption key (KEK) that is stored and managed in a remote KMS. The KMS provider uses gRPC to communicate with a specific KMS plugin. The KMS plugin, which is implemented as a gRPC server and deployed on the same host(s) as the Kubernetes master(s), is responsible for all communication with the remote KMS.