Secure and access your Kubernetes secrets and more

View on GitHub


Trousseau architecture

As per Trousseau roadmap, releases are defined as a MVP or Minimal Viable Product with a well defined set of features.



The version 1.0 target a production grade MVP with a limited set of features matching 3 simple use cases from which features are defined.

Use cases:

Required features for the use cases:

MVP1.0 blueprint overview

The MVP1.0 architecture aims to a single instance approach with a limited the code footprint and components. Trousseau MVP1.0 will consist of several main components working securely to handle CRUD operations:

The below figure shows a basic representation of the flow: mvp1overview

MVP1.0 Use cases

create, read, update, delete (CRUD) operations of Secrets from a CLI perspective

The use case takes into consideration two scenarios related to the creation of secrets:

injecting an existing secret

This scenario takes an already existing secret, like the credentials john/mysuprP@ssw0rd, and injects it within Trousseau, either for safe keeping or for dynamic usage within an application. From a secret perspective, this is what could be called an “almost secret” since the key-value is either existing within another systems or files (happy csv/xls day!) and the pair will transit to Trousseau. This scenario will unmasked the secret and expose it to potential leakage during CLI handling prior to transiting to trousseaud.


From an operation perspective, the create operation will require to format as safely as possible the existing secret in order to transfer it to trousseaud after being process via clectl. Considering the above diagram, the main surface attack exists prior to the transfer to trousseaud.

generating a new scret

This scenario takes a different approach about generated a secret while being totally ofuscated to the user. The user will create a new secret which can be retrieve later from a CLI, API and Kubernetes secret perspective, and even be securely passed to a service like a DB (see next use case details).


Considering the above diagram, generating a secret from a client side will not expose the secret value as the overall process is carried over at the server side.

handle a secret to access an external service like a DB

This use case leverage the generating a new secret and pass it to services for which a package has been define to insure a full secure transition of the credetentials to that service.


provide the basic health status of the service

This use case provides the necessary day 2 operations to monitor the different services involved in providing the Trousseau services. This will be provide via the clectl and an API endpoint towards the trousseaud service.

future work

This section provides an overview of Trousseau vision for the next MVP releases.


The MVP1.5 architecture aims to provide a high available architecture allowing full resilience and hybrid scenario.