Add Auto Unseal Support

[mcforres]

I'm using this module to deploy vault as part of the AWS EKS Blueprints Terraform solution. I noticed that this addon module doesn't currently support Auto Unseal of Hashi Vault. Does it make sense to add this functionality into the module so users can have a production ready Vault cluster?

Soliciting some feedback before writing a PR. I believe the following changes should be considered:

• Expose input variable to enable auto-unseal via KMS (Opt-in)
• Adopt the helm-addon submodule from the EKS Add-on repository. This supports the additional creation of the irsa that could be used by the Vault Pods to access the KMS key for Auto-Unseal
• Include the AWS provider and provision a KMS key/alias/policy to be used for the Auto-Unseal operation
• Conditionally include KMS key id and irsa in Vault helm config

I'm new to Vault, Helm, and EKS so please be gentle :)

[ksatirli]

Hey @mcforres I think support for this would be very welcome and I'm happy to work with you on it.

1.) Opt-in definitely sounds like the way to go. I'd assume that most people would want this, but I can definitely see some orgs preferring it to not be on by default (or be "on" in a different way).

2-4.) This all sounds good to me! Less is always more, but a clean and sane default is the way to go.

[oferchen]

Hey @mcforres I think support for this would be very welcome and I'm happy to work with you on it.

1.) Opt-in definitely sounds like the way to go. I'd assume that most people would want this, but I can definitely see some orgs preferring it to not be on by default (or be "on" in a different way).

2-4.) This all sounds good to me! Less is always more, but a clean and sane default is the way to go.

please merge the pull request to achieve this everything has been already implemented https://github.com/hashicorp/terraform-aws-hashicorp-vault-eks-addon/pull/6 just waiting for blue print update ;-\ (how much longer?)

[sboardwell]

Hi @mcforres and @ksatirli,

I see #11 has taken over this issue. I would like to make a suggestion which may help keep the blueprints and blueprint consumers happier.

I am very much with the opt-in approach. However, the current example means maintaining your own vault-config.yml for anything other than the basic example, which tends to cause drift after some time.

Suggestion

Replace vault config and values with two new variables:

• vault_config_template_name - defaulting to vault-config.yml
• vault_config_template_values - defaulting to {}

The line https://github.com/hashicorp/terraform-aws-hashicorp-vault-eks-addon/blob/7ff99ed01689db6288af82e38edf9cf6f2a8616d/main.tf#L11

could then become

  values           = try(var.helm_config.values, [templatefile("${path.module}/${var.vault_config_template_name}", var.vault_config_template_values)])

This would allow the add-on to supply a couple of "flavours" of config.

• the default no frills vault-config.yml (not requiring any values)
• a vault-config-simple-auto-unseal.yml file (requiring values for the serviceAccount and seal "awskms" sections of the )
• an ha-auto-unseal-auto-unseal.yml file (requiring values for the serviceAccount, seal "awskms", and dynamo backend entry, as in the example)

People could still maintain their own values if they wish, but they could also just supply vault_config_template_name and respective vault_config_template_values to keep up to date with the blueprint.

[sboardwell]

Hi @bryantbiggs, sorry looping you in - hope it's okay. I am not sure if ksatirli is still actively working on this project. Would you have an opinion of the suggestion above?

I can create a PR if it helps.