Multitenancy implementation in Vault

[merll]

Is your feature request related to a problem? Please describe.

Currently there is no implementation of the optional multitenancy in the Vault app. Since multitenancy enforcement used to be the default, this means that teams can never access each other's secrets, with the exception of the team-admin which can access all of them. This could be unexpected to the user if multitenancy is disabled – according to the new default.

Describe the solution you'd like

With multitenancy disabled, it seems intuitive that teams get (read) access to each other's secrets while retaining exclusive write access. When multitenancy is enabled, it could however be desired to selectively share secrets (e.g. though configuration, similar to network policies). While universal read access is simple to implement in Vault policies, selective sharing requires extending the API for configuration.

Unfortunately it is not possible to limit the list permission to only list particular teams, providing full team-privacy as in other Otomi apps. Therefore, limiting the list display of the teams folder would result in breaking the navigation via Vault UI. This is a limitation of Vault and cannot be fixed in Otomi. However, it might be possible to provide shortcuts directly to a team's secret folder.

[staticvoid255]

Great suggestion, in #832 I had different ideas for secrets workflow, but my idea is to abstract Vault away almost completely, which would prevent secrets from ever being shared between namespaces due to relying heavily on automatic path-based writing of secrets to namespaces by the external-secrets operator. From a multitenancy perspective it would make things very easy as it only requires a single Vault admin account and a reader account for external-secrets operator, but would require a Vault client being implemented at API level.

I can imagine a few scenarios in which secrets sharing between teams is a great feature to have, like if you are looking to centrally manage your tenants, but think it opens doors to antipatterns like sharing service principals between tenants.

[staticvoid255]

Bumping this as xternal-secrets operator is currently on its way to being upgraded, which opens new possibilities for Vault, specifically with path-based secrets routing. @Morriz and myself discussed hooking in to existing Otomi KMS features, and extending that to add support for such routing (which would be great as we could support multiple KMS's).

In short - hide Vault away from tenants, support alternative KMS's, perform all write operations in the API, perform all read operations in the ES operator

[Morriz]

I agree, but please stay specific in wording. Vault is not abstracted away, just an optional app when no byo exists. And yes, paths depend on backend chosen

[j-zimnowoda]

Recently we have enforced multitenancy to be always enabled. (isMultitenant=true) @merll is this ticket still relevant?