vault-configurer options and customization

[johnny990]

Preflight Checklist

• [X] I have searched the issue tracker for an issue that matches the one I want to file, without success.
• [X] I agree to follow the Code of Conduct.

Problem Description

Hello, I've already posted similar questions in old repository, but it seems during migration issues were no moved, so I'd like to add it one more time with more details. We have quite strict security requirement in our deployment topology, so it is required to remove root token from vault deployment and in the same time we'd like to have automated init and configuration management. I understand that there is something like chicken-egg problem (we can't init and configure vault instance without root token), so I'm thinking about following options.

Proposed Solution

1. Have an option for vault-configurer to be kind of init job. In this case, vault-configurer will init vault, handle root token the same way it does now, but finishes its job after init (further configuration management will not be possible)
2. Option to disable vault-configurer completely, so vault init and its configuration management will be done manually.
3. Option to separate vault-configurer from vault pod. In this case it would be great to have an option to deploy vault-configurer on separate k8s cluster (for example, we could create roles, access credentials for vault-configurer to manage vault instance inside separate cluster)
4. Option to allow vault-operator manage vault instances on external clusters (something like ArgoCD manages applications on multiple clusters)
5. Option to call vault-configurer on demand (via api?) by providing with root token and asking do its job to configure vault.

Alternatives Considered

• As an alternative we've tried vanilla hashicorp vault with a set of scripts (init jobs) to init and configure vault instance on remote cluster, but I really like bank-vaults, so it would be great to get this functionality in vault-operator
• another alternative is to utilize remote storage (for example AWS KMS or another vault on remote cluster), but it doesn't solve the problem since on "user's" cluster we have access credentials which will allow to get root token from remote store.
• and finally the working solution is to have root token stored in k8s secret, but revoke it immediately after install (as recommended by hashicorp). In this case vault-configurer will just spam logs and it is possible to apply configuration by manually updating secret with admin token and revoke it again after configuration applied.

Additional Information

There's a little bit confusing statement in documentation: https://bank-vaults.dev/docs/concepts/unseal-keys/: HashiCorp [recommends revoking the root tokens](https://developer.hashicorp.com/vault/docs/concepts/tokens#root-tokens) after the initial set up of Vault has been completed. Note: The vault-root token is not needed to unseal Vault, and can be removed from the storage if it was put there via the --init call to bank-vaults.

If I remove root token, vault-configurer will stop working and will spam logs. So, it would be great to have some option to manage it.

[akijakya]

Hi @johnny990, thanks for your interest in Bank-Vaults and the well-thought propositions! Although the development of the operator is currently on hold until we know more about the implications of Hashicorp's license change, this issue definitely has a place on our roadmap.