Page MenuHomeDevCentral
Create Task
Maniphest T2040

Supersede Vault by OpenBao
Open, NormalPublic
Actions

Description

Per T1938, I'd like to propose to supersede Vault by OpenBao.

Plan would be:

  • deploy OpenBao on Complector
  • export the Vault secrets from ops/ and apps/ kv2 store with Medusa
  • import the kv2 secrets to OpenBao with Medusa
  • recreate PKI

Open questions:

  • do we need the web UI? Lot of deployments run without, OpenBao 2.0.1 doesn't ship with (*)
    • if so, do we try to build it with <code>make dev-ui</code>?
  • common security practice is the private key of a PKI can't leave a CA
    • procedure to create the PKI is fully documented in Agora
    • that would call to recreate the PKI, and redeploy roles/core/certificates everywhere (easy as already automated in Salt)
  • keys shares

(*) The main reason is UI exposes both enterprise and open source features, so it's a mess while OpenBao team is trying to remove the codepath to the enterprise features.

PKI-friendly plan:

  • Phase 1 :: Vault and OpenBao in //
    • deploy OpenBao on Complector on a new port
    • generate the root and intermediate CA
    • issue new Vault and bao certificates with the intermediate CA
    • deploy new bao root public certificate on the servers
  • Phase 2 :: secrets migrations
    • export secrets with Medusa, import to Bao
    • Meanwhile, Salt still query Vault
    • test if everything works with Bao
  • Phase 3 :: Bao only
    • edit Bao config to use port 8200
    • shutdown Vault
    • restart Bao (or reload config?) so it uses port 8200 now

Related Objects

Event Timeline

dereckson triaged this task as Normal priority.Oct 3 2024, 15:21
dereckson created this task.
dereckson moved this task from Backlog to Analysis / under discussion on the Servers board.
DorianWinty added a subscriber: DorianWinty.EditedOct 3 2024, 17:23
  • about the UI it could be usefull managing secrets more easyly
  • certificate gen seem good for me
  • key share => is it possible to generate a token like with salt now ?
dereckson added a comment.Oct 3 2024, 17:26

Yes, it's a fork from Vault 1.14 so we've all the features of token generation. back to the shorter s. tokens).

When starting Vault, we need to unseal it or setup auto-unseal. For the manual unseal, Vault uses Shamir algorithm to divide a secret into N keys parts, where M are needed to unseal the vault.

dereckson mentioned this in T2044: Upgrade FreeBSD servers still on 14.0 to 14.1.Oct 3 2024, 21:17
dereckson mentioned this in T2046: Deploy Medusa on devserver role.Oct 5 2024, 12:21
dereckson added a comment.Thu, Sep 18, 22:04

So, there is a new reason to do the upgrade.

We're considering adopting Terraform/OpenTofu to provision things actively maintained there, less on Salt:

  • VMware ESXi
  • Vault provisioning - Salt has out of the box support for policies, everything else we need to code it

Terraform needs to maintain an internal state to be able to detect changes, ie Terraform doesn't play the idempotent game to analyze resources, it memorizes instead what has been previously deployed.

With OpenTofu, this state can be encrypted using OpenBao encryption-as-a-service. The last supported version is 1.14 for Vault, after that, they only support OpenBao. Currently, both are API compatible, but in the future, that could change.

Also the UI is now directly shipped with bao, without any need for a build flag anymore.

@DorianWinty could you run on your machine dnf install openbao ; bao server -dev? You'll be able to check if the UI is OK. It seems the same than Vault for me.

dereckson updated the task description. (Show Details)Thu, Sep 18, 22:05
dereckson updated the task description. (Show Details)Thu, Sep 18, 22:22
Nasqueron DevCentral · If it had been much bigger the moon would have had a core of ice. · Powered by Phabricator