Move the generation of vault credentials from ansible to terraform

[pdmthorsrud]

Feature description

I suggest we move the whole generation of secrets used in the module over to the module itself, and remove it from the ansible scripts. The ansible scripts are not part of the module, meaning anyone using our module would need to create secrets in their vault before using this. We could still keep all the funtionality we have now, of being able to use user-provided secrets, as well as setting a custom path to the vault secrets, but also bundle in a creation and usage of secrets in vault with the module itself.

Why is it needed?

User experience

Suggestion(s)/solution(s) [Optional]

Take this part, and convert it to terraform code
https://github.com/fredrikhgrelland/terraform-nomad-presto/blob/6fbb7ae2e50cd6c06fab59526ef6a103872aaaae/dev/ansible/00_generate_secrets_vault.yml#L1-L10

Using the vault provider

Definition of done

Ansible code to generate secrets is moved into the terraform code in the module itself
All existing features are kept

Checklist (after created issue)

• Added label(s)
• Added to project
• Added to milestone

[zhenik]

While deploying a module you might have the token from Vault with limited access rights. Like only "read" capabilities.

path "secret/data/dev/minio" {
  capabilities = ["read"]
}

I would suggest avoiding coupling between module and managing Vault policies.

[zhenik]

As an additional idea, we could think about a separate module(s) for managing:

• Vault policies
• Consul policies
• Nomad policies

or

• Hashicorp policy manager module, just one common for Policy management for all 3 services at once.

Policies exist in separate contexts for each module, you have the opportunity to map policies with roles and make tokens via Vault.

The same idea for Consul intentions. Basically, avoid coupling.

NB even having these modules, we might end up with different access rights, who can manage policies, who can deploy modules with services, and it should be two different sets of identities, credentials, and rights to do so.

[pdmthorsrud]

We just had a discussion about this, here's my takeaway:

We both agree that putting something like this inside the presto-module is not necessarily a good thing, because this is not a "presto"-thing, meaning it doesn't belong in the presto-module. Therefore, Nikita's suggestion of putting the creation of secrets (and potentially other features) into its own terraform module makes a lot of sense. The same goes for the creation of intentions as well, which should potentially also be its own module.

However, in the context of the system we are about to use this module in, it might be beneficial to have some simple code bundled with the module that creates secrets in vault. This all depends on whether we will have to create our own credentials or not.

[pdmthorsrud]

We just had a discussion about this, here's my takeaway:

We both agree that putting something like this inside the presto-module is not necessarily a good thing, because this is not a "presto"-thing, meaning it doesn't belong in the presto-module. Therefore, Nikita's suggestion of putting the creation of secrets (and potentially other features) into its own terraform module makes a lot of sense. The same goes for the creation of intentions as well, which should potentially also be its own module.

However, in the context of the system we are about to use this module in, it might be beneficial to have some simple code bundled with the module that creates secrets in vault. This all depends on whether we will have to create our own credentials or not.

when all that is said and done, why don't we just create a tiny module that takes a path and keys as input, and create random strings, and output their paths? Maybe an hour of work, not even that

[pdmthorsrud]

I would like to start POC'ing a little on this one, so I can get my head around our credentials and policies
https://github.com/pdmthorsrud/terraform-vault-credentials