Trousseau
Trousseau is built against the following principles:
- 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
Starting with version 1.1.0, Trousseau introduced a Zero trust security model addressing 5 out 6 key principles:
| # | Principle | Trousseau |
|---|---|---|
| ✅ | single strong source of user identity | integrate with a remote KMS |
| ✅ | user authentication | support separation of duties |
| ✅ | machine authentication | Kubernetes ServiceAccount & KMS Kubernetes Auth method |
| additional context check, such as policy compliance and device health | a GitHub issues | |
| ✅ | authorization policies to access an application | KMS policy & role |
| ✅ | access control policies within an application | dedicated token recovered via ConfigMap |
The development language has been chosen based on the ecosystem in which Kubernetes resources are developped.
To provide the maximum flexibility when being integrated within an end-to-end DevOps journey, using a native Kubernetes API approach allows to reduce the next to call for custom API or run extra CLI tooling in runners.
As an extra benefit, this will reduce the need for a DevOps team to learn new niche skills and have a clear separation of duties with the Security team.
To support the above, Trousseau is leveraging the native Kubernetes KMS provider framework to secure secrets with a remote KMS while still being safe locally within the Kubernetes etcd by acting as a KMS broker between the DevOps team, the kube-apiserver and the remote KMS.
Trousseau aims to provide support for multiple KMS providers. As per version 1.1.0 of Trousseau, the following KMS providers are supported:
| KMS Provider | Version | Status |
|---|---|---|
| HashiCorp Vault (Community & Enterprise) | 1.9.3 | ✅ |
| HashiCorp Cloud Vault Enterprise | n/a | ✅ |