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?

What is Trousseau?

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.

What is Trousseau for?

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.

What does Trousseau solve?

By using Trousseau, the user will address the following flaws:

• 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, ...

What are Trousseau's design principles?

• security, security, security!
• develop in Go
• respectful of Kubernetes KMS provider framework and Secret API objects
• architecture to integrate with multiple KMS provider solutions
• architecture to integrate with 3rd party like SOPS

How does Trousseau accomplish its goals?

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.