Manage backend key for vault addons#

The problem#

If you are using the s3 backend configuration for terraformed parts of the vault role, you might encounter a problem of backend state key overlap.

One Solution#

If you look into roles/vault/tasks/main.yml you will find this section:

roles/vault/tasks/main.yml#
66- name: "Include requested vault addons"
67  include_tasks:
68    file: "{{ role_path }}/tasks/tf_addons/_{{ _current_conf_addon }}.yml"
69    apply:
70      tags:
71        - addons
72  loop: "{{ hs_vault_enabled_addons }}"
73  loop_control:
74    loop_var: _current_conf_addon
75  when:
76    - __hs_vault_is_master
77  tags:
78    - addons

As you can read, addons are applied in a sequence and there is a loop_var statement.

The idea is to rely on this mechanism to handle your key dynamism. You could configure your vault role like in this example:

1hs_vault_terraform_backend_type: 's3'
2hs_vault_terraform_backend_config:
3  key: "vault_{{ _current_conf_addon | default('no_current_conf_addon') }}"
4  bucket: "..."

In this way, when the hs_vault_terraform_backend_config will be evaluated during the applicance loop the property key will have a different value for each loop, directly linked to the current addon being applied.

The | default('no_current_conf_addon') here is only to detect any evaluation outside of the applicance loop that could occur.