Problem description

<Clearly define the issue or challenge the epic seeks to address, outlining the impact on users or the system>

When a service provider runs a multi-tenant deployment, where each tenant (customer) keeps his data in a distinct database, they sometimes want to manage the key for his data-at-rest encryption himself. That ensures the service provider can’t decrypt the customer’s data if the customer stops providing the key. From the PSMDB perspective, this means each database can have its own external encryption key.

Solution hypothesis

<Describe the high-level approach or plan for addressing the problem, focusing on how the proposed changes will resolve the issue>

The solution is to have each and every database encrypted separately by an external key provided by their customer (user of the software that uses a multi-tenant database instance), not themselves. In other words, a customer could stop providing the key, and their data in this multitenant database would be unrecoverable. Something similar to Azure SQL's TDE with Bring your own key (BYOK): plus each and every logical MongoDB separately.

Functional and non-functional requirements

<Specify the system’s capabilities and behaviors needed for the solution (functional), along with performance, security, and usability constraints (non-functional)>

Success criteria

<List the conditions that must be met for the epic to be considered complete and for the solution to be accepted by stakeholders>

Dependencies

<Identify other projects, teams, or tasks the epic relies on or is linked to, ensuring smooth execution and integration>