-
Notifications
You must be signed in to change notification settings - Fork 193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help with transit auto-unseal example #323
Comments
For transit autounsealing you will need another vault being having its transit secret engine properly configured. I usually do a userpass login to the transit vault, register the token and pass it to this role. |
@FalcoSuessgott thanks for your reply. So I have a vault instance installed on my local machine, to use for the transit token setup as you suggest. I also have 3 vault servers on a remote server in HA mode I will setup with the transit autounseal. Here is what I have now: I have installed the community.hashi_vault collection.
My follow up questions:
Thx. |
This could help you - name: Unseal Token
uri:
url: "{{ unseal_addr }}/v1/auth/userpass/login/{{ unseal_user }}"
method: POST
validate_certs: false
body_format: form-urlencoded
body:
password: "{{ unseal_password }}"
status_code: 200
run_once: true
delegate_to: 127.0.0.1
register: unseal_token
- name: set facts
set_fact:
vault_transit_token: "{{ unseal_token.json.auth.client_token }}"
run_once: true
delegate_to: 127.0.0.1 after this you can call the role in |
@FalcoSuessgott apologies for the delayed response. Thanks for the above post. I am still a little lost.
Thanks. |
Here could be a starting point for you: - hosts: vault_raft_servers
gather_facts: false
vars:
unseal_user: ...
unseal_password: ....
pre_tasks:
- name: Wait for SSH Connection
wait_for_connection:
timeout: 60
- name: Gathering facts
setup:
- name: Unseal Token
uri:
url: "{{ unseal_addr }}/v1/auth/userpass/login/{{ unseal_user }}"
method: POST
validate_certs: false
body_format: form-urlencoded
body:
password: "{{ unseal_password }}"
status_code: 200
run_once: true
delegate_to: 127.0.0.1
register: unseal_token
- name: set facts
set_fact:
vault_transit_token: "{{ unseal_token.json.auth.client_token }}"
run_once: true
delegate_to: 127.0.0.1
roles:
- role: roles/ansible-role-vault
become: true
become_user: root
vars:
[...]
post_tasks:
- name: Get vault init status
uri:
url: "{{ vault_api_addr }}/v1/sys/init"
method: GET
validate_certs: false
status_code: 200
run_once: true
delegate_to: 127.0.0.1
register: init_status
- name: Initialize Vault if not initialized
uri:
url: "{{ vault_api_addr }}/v1/sys/init"
method: POST
validate_certs: false
body: '{ "recovery_shares": {{ unseal_shares | int }}, "recovery_threshold": {{ unseal_threshold | int }} }'
status_code: 200
body_format: json
run_once: true
delegate_to: 127.0.0.1
register: recovery_keys
when:
- not init_status.json.initialized
- name: Write Keys to $PWD
copy:
content: "{{ recovery_keys.json | to_nice_json }}"
dest: "{{ key_file_path }}.json"
mode: '0600'
run_once: true
delegate_to: 127.0.0.1
when:
- not init_status.json.initialized You can debug this when you ssh into your vms or get a shell in the container and watch the logs of vault (usually journalctl -uf vault) and inspect the config files under /etc/vault.d/. hope this helps. |
@FalcoSuessgott I am getting a lot of 503 errors related to the vault initialization in the post_tasks section so haven't been able to get past that. Looks like the vault init is failing. I am able to get the vault cluster up and running without the inclusion of the pre /post tasks.
Similar to the issue in this thread, where the suggested solution is to initialize the vault cluster manually. Also, it looks like the auto-unseal steps happens in the main role before the initialization of steps in the post_tasks? |
Is there an example of how to apply the transit auto-unseal variables with this role? I have a cluster with 3 vault servers in HA mode. Will like to implement transit auto-unseal through the role instead of doing it manually. I am confused about how/where to get the token from in the first place.
Is this enough on each vault server node to get it setup?
The text was updated successfully, but these errors were encountered: