The traditional credentials handling practices enforce a clear separation of concerns between application and infrastructure teams.
However, Kubernetes centralized credentials through the secret and configmap API objects within etcd with an encryption layer.
More here Security or with Kubernetes Secrets Handbook
Kubernetes introduces a KMS plugin framework to support access to an external security (hardware or software) module and enable an envelope encryption practice.
The Kubernetes API server will encrypt plaintext data with a data key, request kleidi to encrypt the data key with a third-party key, and store all the encrypted payload in etcd.
Reading the payload will require access to the third-party provider via Kleidi.
- KMSv2 with Kubernetes 1.29 and onwards.
- PKCS#11 interface to SoftHSM deployed on the control plane nodes.
- HashiCorp Vault Community/Enterprise integration More here Implementation
- (v)TPM integration (see R&D)
- AWS/Azure Key Vault integration
- Delinea/Thycotic integration
We believe in a space for everyone and we embrace the following code of conduct.
The essence of open source is sharing and contributing to knowledge. The guidelines are available here.
We take security and trust seriously. If you believe that you have found a security issue in this project, *please disclose responsibly the details by following the security policy.
Initially, romdalf founded Trousseau in 2019 and released a production-grade KMSv1 provider plugin during his tenure at Ondat.
With the Kubernetes project moving to KMSv2 stable at 1.29 and KMSv1 being deprecated since 1.27, a decision needed to be made regarding rewriting the plugin, leading to the creation of kleidi.
The origin is Greek, and the meaning is "key". (Source: Wikipedia)