Change Details

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

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

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