Add support for Vault to OpenBao migration #85

seunghun1ee · 2026-01-09T14:02:04Z

No description provided.

gemini-code-assist · 2026-01-09T14:02:23Z

Summary of Changes

Hello @seunghun1ee, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a robust and automated solution for migrating existing HashiCorp Vault deployments to OpenBao using Ansible. It provides a structured approach to handle both single-node and High Availability Vault environments, ensuring that critical data, configurations, and TLS settings are seamlessly transitioned. The changes focus on orchestrating the storage backend migration, deploying OpenBao, and managing its lifecycle, thereby streamlining the process of adopting OpenBao.

Highlights

New Ansible Playbook for HA Migration: Introduced playbooks/ha_vault_bao_migration.yml, a dedicated Ansible playbook designed to orchestrate the migration of High Availability (HA) Vault clusters to OpenBao, ensuring a smooth transition for multi-node setups.
Comprehensive Migration Role: Added a new Ansible role roles/vault_bao_migration/ which encapsulates all necessary tasks for migrating from Vault to OpenBao. This role includes prerequisites, storage backend migration (from Consul to Raft), and specific logic for both single-node and HA migrations.
Storage Backend Migration to Raft: Implemented tasks within roles/vault_bao_migration/tasks/raft.yml to handle the migration of Vault's storage backend from Consul to Raft, including snapshotting Consul data, templating migration configurations, and restarting Vault with the new Raft backend.
OpenBao Deployment and Unsealing: Integrated the deployment of OpenBao instances using the stackhpc.hashicorp.openbao role and automated the unsealing process, including temporary unsealing for snapshot restoration and final unsealing, ensuring OpenBao is operational post-migration.
TLS Certificate and CA Copying: Added steps to automatically copy existing TLS keys, certificates, and CA files from the Vault configuration directory to the OpenBao configuration directory, preserving secure communication settings during the migration.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request introduces a comprehensive Ansible role and playbook for migrating from HashiCorp Vault to OpenBao. The separation of logic for single-node and HA migrations is well-designed. However, the review identified several significant issues that need to be addressed. There is a critical logic flaw in the HA migration playbook concerning how new OpenBao nodes join the cluster, which will cause the migration to fail for followers. Additionally, there are multiple instances of unreliable pauses instead of robust polling, insecure file permissions, and inconsistencies in configuration variables. The provided feedback includes specific code suggestions and recommendations to fix these issues, improve reliability, and enhance the security of the migration process.

gemini-code-assist · 2026-01-09T14:05:14Z

playbooks/ha_vault_bao_migration.yml

+        openbao_raft_leaders:
+          - "{{ (new_leader_api_addr_query.json.leader_address if inventory_hostname == vault_raft_leader else vault_leader_api_addr) | urlsplit('hostname') }}"


The logic for setting openbao_raft_leaders is incorrect for follower nodes. During the HA migration, followers are migrated first. This logic incorrectly makes them try to join the old Vault leader (vault_leader_api_addr) instead of forming a new OpenBao cluster. The first migrated follower should initialize the new OpenBao cluster, and all subsequent nodes should join it.

A more robust approach is to designate the first host in the ordered_vault_hosts group as the seed for the new OpenBao cluster. All other nodes will then join this seed node.

openbao_raft_leaders: "{{ [groups['ordered_vault_hosts'][0]] if inventory_hostname != groups['ordered_vault_hosts'][0] else [] }}"

gemini-code-assist · 2026-01-09T14:05:14Z

playbooks/ha_vault_bao_migration.yml

+          ansible.builtin.wait_for:
+            timeout: 10


Using wait_for with only a timeout creates an unreliable pause. A fixed delay may not be sufficient for a new leader to be elected in all environments. This is especially problematic in the context of this playbook where the step-down is executed on the last Vault node, meaning there are no other nodes to elect as a new leader. This part of the logic seems flawed and should be re-evaluated. If a pause is truly needed, ansible.builtin.pause is more explicit, but a polling mechanism that waits for a specific condition is always more robust.

gemini-code-assist · 2026-01-09T14:05:14Z

roles/vault_bao_migration/defaults/main.yml

+
+openbao_protocol: "{{ 'https' if openbao_tls_key and openbao_tls_cert else 'http' }}"
+
+openbao_api_addr: "{{ openbao_bind_addr ~ ':' ~ openbao_api_port }}"


The openbao_api_addr default value is missing the protocol (http:// or https://). The OpenBao api_addr configuration parameter requires a full URL, including the protocol. This is inconsistent with the vault_api_addr definition in this same file and the documentation in the README, which specifies 'Full URL including protocol and port'.

openbao_api_addr: "{{ openbao_protocol }}://{{ openbao_bind_addr }}:{{ openbao_api_port }}"

gemini-code-assist · 2026-01-09T14:05:15Z

roles/vault_bao_migration/tasks/raft.yml

+  ansible.builtin.file:
+    path: "{{ vault_staging_dir_path }}"
+    state: directory
+    mode: '0777'


Setting directory permissions to 0777 is insecure as it grants read, write, and execute permissions to everyone. The permissions for this staging directory should be more restrictive. Please use a more secure mode like 0750 or 0755 that follows the principle of least privilege.

mode: '0755'

gemini-code-assist · 2026-01-09T14:05:15Z

roles/vault_bao_migration/tasks/single_node_migration.yml

+  ansible.builtin.wait_for:
+    timeout: 10


Using wait_for with only a timeout creates an unreliable pause. After restoring a snapshot, OpenBao will restart and become sealed. Instead of a fixed pause, you should poll the /v1/sys/seal-status endpoint until the sealed status is true. This reliably indicates that the restore process is complete and the instance is ready to be unsealed with its original keys.

gemini-code-assist · 2026-01-09T14:05:15Z

roles/vault_bao_migration/README.md

+1. Print to Ansible log output (`openbao_log_keys`)
+1. Set a `openbao_keys` fact (`openbao_set_keys_fact`)
+1. Write to a file (`openbao_write_keys_file`)


The numbered list is using 1. for all items. For clarity and correctness in Markdown, it should be an incrementing list (1., 2., 3.).

Suggested change

1. Print to Ansible log output (`openbao_log_keys`)

1. Set a `openbao_keys` fact (`openbao_set_keys_fact`)

1. Write to a file (`openbao_write_keys_file`)

1. Print to Ansible log output (`openbao_log_keys`)

2. Set a `openbao_keys` fact (`openbao_set_keys_fact`)

3. Write to a file (`openbao_write_keys_file`)

gemini-code-assist · 2026-01-09T14:05:15Z

roles/vault_bao_migration/README.md

+  tasks:
+    - name: Enable bao secrets engines
+      hashivault_secret_engine:
+        url: "https://vault.example.com:8200"


The example URL https://vault.example.com:8200 could be confusing in a playbook for OpenBao post-deployment configuration. To avoid ambiguity, consider changing vault.example.com to something that more clearly represents OpenBao, such as bao.example.com.

Suggested change

url: "https://vault.example.com:8200"

url: "https://bao.example.com:8200"

gemini-code-assist · 2026-01-09T14:05:15Z

roles/vault_bao_migration/tasks/raft.yml

+    - name: Check the number of the raft peers
+      ansible.builtin.shell:
+        cmd: >
+          docker exec -e VAULT_TOKEN=$VAULT_TOKEN -e VAULT_ADDR=$VAULT_ADDR
+          {% if vault_tls_ca != "" %} -e VAULT_CAPATH=$VAULT_CAPATH {% endif %}
+          {{ vault_docker_name }}
+          vault operator raft list-peers -format=json | jq -r '.data.config.servers | length'
+      register: vault_raft_peer_length
+      environment:
+        VAULT_ADDR: "{{ vault_api_addr }}"
+        VAULT_TOKEN: "{{ vault_root_token }}"
+        VAULT_CAPATH: "{{ '/vault/config/' + vault_tls_ca if vault_tls_ca != '' else omit }}"
+      changed_when: false


Using ansible.builtin.shell with jq introduces an external dependency on jq and can be less robust than using Ansible's built-in capabilities. You can achieve the same result by using the community.docker.docker_container_exec module to get the raw JSON output and then processing it with Ansible's from_json and length filters. This approach is more idiomatic to Ansible and removes the external dependency.

gemini-code-assist · 2026-01-09T14:05:15Z

roles/vault_bao_migration/tasks/single_node_migration.yml

+    owner_id: 100
+    group_id: 1000


Hardcoding the owner_id and group_id is brittle, as these numeric IDs can vary across systems. If possible, use user and group names (e.g., openbao). If numeric IDs are necessary for this module, consider defining them as variables in defaults/main.yml to make them more manageable and easier to override.

gemini-code-assist · 2026-01-09T14:05:15Z

roles/vault_bao_migration/tasks/single-node-migration.yml

+- name: Unseal OpenBao
+  ansible.builtin.import_role:
+    name: stackhpc.hashicorp.vault_unseal
+  vars:
+    vault_api_addr: "{{ openbao_api_addr }}"


This task to unseal OpenBao implicitly relies on the vault_unseal_keys variable being populated with the original Vault unseal keys. This is not obvious from the playbook and can lead to failures if the variable is not set correctly by the user. It would be good practice to:

Add a check to ensure vault_unseal_keys is defined and not empty before attempting to unseal.

Document this requirement clearly in the role's README.md file.

and fix the old variable

Since ha_migration.yml is a separate playbook, migration_* variables from vault_bao_migration role may not be defined when the playbook is being used. Added default values to make the playbook safe to run without optional variables.

To acurately compare hostname and vault ha-status results

This option needs to be explictly set when using integrated storage backend (Raft) from Vault 1.20

As OpenBao's migration guide [1] is only tested against Vault 1.14.1 and OpenBao 2.2.0 [1] https://openbao.org/docs/guides/migration/

This reverts commit e5b653f.

seunghun1ee self-assigned this Jan 9, 2026

gemini-code-assist bot reviewed Jan 9, 2026

View reviewed changes

seunghun1ee force-pushed the vault-bao-migration branch 3 times, most recently from dc56f29 to a8a4561 Compare January 12, 2026 16:11

Alex-Welsh and others added 24 commits January 16, 2026 11:07

new role init

cfff63c

WIP: single node migration working

4daa520

Add cluster_addr to vault_raft_config

88f8b4a

Comment out WIP task

e3943f9

Fix playbooks attempting to unseal too fast

854ba14

Query leader&followers for HA

1e3f715

Make Raft migration compatible with HA

a6b4bcd

Fix single node migration

6b50f46

WIP: HA migration to openbao

0479784

Simplify vault to openbao steps

a0eedf2

Get new leader from different host

4e5dd1e

clean up

6f6ab70

Refactor prereq

1dd0ba2

Clean up default variables

8c90a8f

Fix broken owner/group for openbao certs

91cb4ac

Fix variable on ha migration playbook

b01c29d

Test serial include_tasks

1ccb9a7

rename single node playbook

27fb5ea

Try using looping task on HA migration

35ad1cf

Test delgation

1e314df

Move ansible_host to apply for include_role tasks

7aea677

Use hostvar for api address

33a9562

and fix the old variable

Try putting all vars in apply for roles

303f51e

Try using playbook wrapper instead of role

cbe7ca4

seunghun1ee added 4 commits January 16, 2026 11:07

Clean up

276895d

Set default values for migration_* vars

9dfbd23

Since ha_migration.yml is a separate playbook, migration_* variables from vault_bao_migration role may not be defined when the playbook is being used. Added default values to make the playbook safe to run without optional variables.

Mark mandatory variables

93f5299

Add readme

edf7b12

seunghun1ee force-pushed the vault-bao-migration branch 12 times, most recently from b145f17 to 172a03e Compare January 16, 2026 14:27

seunghun1ee added 2 commits January 16, 2026 14:39

Add single node migration CI

f320f8d

Replace inventory_hostname to ansible_facts.hostname

184de94

To acurately compare hostname and vault ha-status results

seunghun1ee force-pushed the vault-bao-migration branch from 172a03e to 184de94 Compare January 16, 2026 14:39

Temp: display vault logs at the end

7220f52

seunghun1ee force-pushed the vault-bao-migration branch 2 times, most recently from 00d6d48 to 17f27f2 Compare January 16, 2026 15:15

Add disable_mlock option for Vault Raft deployment

e5b653f

This option needs to be explictly set when using integrated storage backend (Raft) from Vault 1.20

seunghun1ee force-pushed the vault-bao-migration branch from 17f27f2 to e5b653f Compare January 16, 2026 15:20

seunghun1ee added 5 commits January 16, 2026 15:46

Temp: Display root token and unseal keys

ae8df67

Pin Docker tags of Vault and OpenBao

d2baca2

As OpenBao's migration guide [1] is only tested against Vault 1.14.1 and OpenBao 2.2.0 [1] https://openbao.org/docs/guides/migration/

Revert "Add disable_mlock option for Vault Raft deployment"

684b132

This reverts commit e5b653f.

Test waiting Vault before unsealing

109dd99

Temp: get curl result

0fa4fba

		openbao_raft_leaders:
		- "{{ (new_leader_api_addr_query.json.leader_address if inventory_hostname == vault_raft_leader else vault_leader_api_addr) \| urlsplit('hostname') }}"


		openbao_protocol: "{{ 'https' if openbao_tls_key and openbao_tls_cert else 'http' }}"

		openbao_api_addr: "{{ openbao_bind_addr ~ ':' ~ openbao_api_port }}"

	url: "https://vault.example.com:8200"
	url: "https://bao.example.com:8200"

Add support for Vault to OpenBao migration #85

Are you sure you want to change the base?

Add support for Vault to OpenBao migration #85

Uh oh!

Conversation

seunghun1ee commented Jan 9, 2026

Uh oh!

gemini-code-assist bot commented Jan 9, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 9, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants