Skip to content
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

Open
vacquah opened this issue Dec 14, 2022 · 6 comments
Open

Help with transit auto-unseal example #323

vacquah opened this issue Dec 14, 2022 · 6 comments

Comments

@vacquah
Copy link

vacquah commented Dec 14, 2022

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?

    vault_transit: true
    vault_transit_address: http://127.0.0.1:8200  ???
    vault_transit_token: '' ????
    vault_transit_disable_renewal: false
    vault_transit_key_name: 'autounseal'
    vault_transit_mount_path: "transit/"
    vault_transit_tls_skip_verify: true
@FalcoSuessgott
Copy link
Collaborator

For transit autounsealing you will need another vault being having its transit secret engine properly configured.
You can then use this ansible role and authenticate to that vault (lets say in the pre tasks of the playbook), get the token and pass it to this role.

I usually do a userpass login to the transit vault, register the token and pass it to this role.
All the variables you listed need to be defined.

@vacquah
Copy link
Author

vacquah commented Dec 22, 2022

@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.

 pre_tasks:
    - name: retrieve token from localhost vault
      community.hashi_vault.vault_read:
        url: http://127.0.0.1:8200
        auth_method: userpass
        username: user
        password: '{{ passwd }}'
      register: token

My follow up questions:

  1. I am not sure how to retrieve the token using the above. the "register" option - what should it be?
  2. how do I pass the registered token to the main vault ansible role? is the registered token stored in a variable ?
  3. In the transit code above, what should the transit address be? ( the ip address of each server node or 127.0.0.1:8200

Thx.

@FalcoSuessgott
Copy link
Collaborator

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 roles section and the variable vault_transit_token should be set

@vacquah
Copy link
Author

vacquah commented Dec 27, 2022

@FalcoSuessgott apologies for the delayed response. Thanks for the above post. I am still a little lost.

  1. do I create a new role or task with this and reference it in the roles section?
  2. do i store the variables {{ unseal_addr }}, {{ unseal_user }} and {{ unseal_password }} in my env file?

Thanks.

@FalcoSuessgott
Copy link
Collaborator

  1. You could put this in the pre_task section of your paybook
  2. Yes they are normal ansible variables you can define them anywhere you want ( I put them in my group vars since I have a different transit engine configured for my environments (prod, dev, stage) see: https://medium.com/@toja/organizing-group-vars-files-in-ansible-2b5f5a1568b3). I suggest you define those vars just in the vars section of you playbook:

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.

@vacquah
Copy link
Author

vacquah commented Jan 1, 2023

@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.

Jan 01 13:09:32 vault-01 sh[16731]: 2023-01-01T13:09:32.191-0500 [ERROR] core: failed to retry join raft cluster: retry=2s err="failed to get raft challenge"
Jan 01 13:09:34 vault-01 sh[16731]: 2023-01-01T13:09:34.192-0500 [INFO]  core: security barrier not initialized
Jan 01 13:09:34 vault-01 sh[16731]: 2023-01-01T13:09:34.195-0500 [INFO]  core: attempting to join possible raft leader node: leader_addr=http://10.1.20.22:8200
Jan 01 13:09:34 vault-01 sh[16731]: 2023-01-01T13:09:34.197-0500 [INFO]  core: attempting to join possible raft leader node: leader_addr=http://10.1.20.21:8200
Jan 01 13:09:34 vault-01 sh[16731]: 2023-01-01T13:09:34.206-0500 [ERROR] core: failed to get raft challenge: leader_addr=http://10.1.20.22:8200
Jan 01 13:09:34 vault-01 sh[16731]:   error=
Jan 01 13:09:34 vault-01 sh[16731]:   | error during raft bootstrap init call: Error making API request.
Jan 01 13:09:34 vault-01 sh[16731]:   |
Jan 01 13:09:34 vault-01 sh[16731]:   | URL: PUT http://10.1.20.22:8200/v1/sys/storage/raft/bootstrap/challenge
Jan 01 13:09:34 vault-01 sh[16731]:   | Code: 503. Errors:

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants