Secrets creation/modification entirely within console

[staticvoid255]

Is your feature request related to a problem? Please describe. I find the team-secrets creation process to be not user-friendly and in code more complex than it needs to be

Describe the solution you'd like I'd like the whole team secrets creation and management process to happen within the console (from a user perspective). External-secrets (not KES) already allows you to specify path-based writing of Vault secrets to namespaces, so since our teams are 1:1 with their namespaces, we could simply generate that path in the API and write directly to Vault, then have external-secrets automatically sync it to the namespace.

Using a single Otomi-api account to handle writing to and from Vault also supports shared/external Vault instance scenarios better.

This would of course require an upgrade from kubernetes-external-secrets to external-secrets

[Morriz]

Would be great to see that implemented. But it involves more than you think. Secrets need to be created in Vault somehow, and External Secrets only pulls secrets, so we have to:

• build a vault client (openapi published?)
• create an otomi-task that uses the client to create these secrets

[staticvoid255]

We could even just remove the secrets feature from the console, then simply have users create their secrets in Vault and have external-secrets automatically sync those to the team namespace based on the above mentioned path-based writing. We already have the Vault user and permission setup to support this.

[Morriz]

"Automatically"? There is always work involved. K8s is a beast which eats declarations. Which actor creates those declarations do you think?

Console is the one stop solution for most things, until we hand over to the apps we promote. If simple use cases make a users life easier, than we create a story to do it in the console. Added advantage is that we can plug different secrets solutions. Vault is just one

[staticvoid255]

I think this solution would provide an extremely simple and user friendly way to implement multi-tenant secrets management rather than the complex integration that we have now with issues like otomi-admin account not being able to see secrets, and the roundabout user experience. All you need is one Vault admin to write secrets on behalf of the API, and one reader account for external-secrets, then apply multitenancy at the level of the building of the path to which a given secret is written. One great side-effect of this is providing a generic interface for secrets to which we can easily add more KMS clients in the future.

@j-zimnowoda any thoughts on this?

[Morriz]

So, to continue on my obervation, for your approach we would have to create and maintain multiple api interfaces for the different endpoints we support: Vault, Azure Keyvault, AWS etc etc. This is simply not desirable, and especially not from a long term vision towards such integrations.

[Morriz]

I just don’t see a man in the middle approach where otomi console is the creator of secrets in multiple exotic storage endpoints. I do understand the friction of needing to create secrets in otomi, so I propose a better solution (if possible):

Workflow:

1. Secret is made in app (Azure KV, Vault etc)
2. Webhook is called that triggers our (new) daemon
3. Daemon creates external-secret
4. Otomi just scans and reads in existing external-secrets and lists them.

This approach still makes the user use the secrets app that was intended, with all the AuthZ in place as expected.

[Morriz]

If this gets prio we should have a discussion about the details. I have a detailed vision already that I would like to share.

[j-zimnowoda]

Closing as Hashicorp Vault is not gonna be used with Otomi.