1"use strict";(self.webpackChunkwebsite=self.webpackChunkwebsite||[]).push([["17358"],{91895(e){e.exports=JSON.parse('{"archive":{"blogPosts":[{"id":"release-v2-6-0","metadata":{"permalink":"/blog/release-v2-6-0","source":"@site/content/blog/2026-08-18-release-v2-6-0.mdx","title":"Announcing OpenBao v2.6!","description":"We are thrilled to announce the availability of OpenBao v2.6, adding per-namespace sealing and the new workflow engine for cross-plugin communication!","date":"2026-08-18T00:00:00.000Z","tags":[{"inline":true,"label":"release","permalink":"/blog/tags/release"},{"inline":true,"label":"announcement","permalink":"/blog/tags/announcement"}],"readingTime":2.76,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Announcing OpenBao v2.6!","description":"We are thrilled to announce the availability of OpenBao v2.6, adding per-namespace sealing and the new workflow engine for cross-plugin communication!","slug":"release-v2-6-0","authors":["cipherboy"],"tags":["release","announcement"],"image":"https://openssf.org/wp-content/uploads/2026/08/OpenSSF-Blog-Graphics-87.png"},"unlisted":false,"nextItem":{"title":"Flux and OpenBao: Secrets and Signatures","permalink":"/blog/flux-openbao-secrets-signatures"}},"content":"import Head from \'@docusaurus/Head\';\\n\\n<Head>\\n <link rel=\\"canonical\\" href=\\"https://openssf.org/blog/2026/08/06/announcing-openbao-v2-6/\\" />\\n</Head>\\n\\n\\n\\nWe are thrilled to announce [the availability](https://openbao.org/downloads/?version=v2.6.1) of [OpenBao v2.6](https://openbao.org/community/release-notes/2-6-0/), adding per-namespace sealing and the new workflow engine for cross-plugin communication!\\n\\nOur most collaborative release to date, v2.6 features contributions from 42 first-time contributors, 27 individuals contributing multiple changes, and 8 users with double-digit change counts. Simply fantastic work and a big thanks to the community that makes this happen!\\n\\n:::info\\n\\nOpenBao v2.6.x has been out for a month now and v2.7.x will soon follow, stay\\ntuned for more releases!\\n\\n:::\\n\\n\x3c!-- truncate --\x3e\\n\\n## Key highlights of this release\\n\\nWe saw many innovative improvements this release:\\n\\n- **Namespace Sealing**: Allows construction of an additional Shamir seal and scoped barrier keyring on namespace creation to partition tenant storage with distinct cryptographic key material. This allows tenants to revoke instance operator\'s access to their namespace via seal operation without impacting other tenants.\\n- **Auto Unseal Plugins**: Adds a new kms plugin type in the configuration file which enables auto-unseal mechanisms to be distributed as external binary plugins. This allows a decoupled release process and easier adoption of third-party key management systems (KMSes).\\n- **Workflows**: Adds new endpoints under sys/workflows to allow operators to create multi-request workflows for cross-plugin communication and allows users to execute them. This can unlock in-process, organization-specific native governance of OpenBao or simplified facades over multiple individual pieces of OpenBao functionality.\\n- **Distroless container images**: Introduces a new container image variant based on distroless/static, available as openbao-distroless. The only executable contained in these images is OpenBao itself.\\n- **Authenticated root generation**: New sys/generate-root-token endpoints are available as replacements for the deprecated unauthenticated ones.\\n\\nThere were also over 38 other feature improvements to our core plugins; refer to the [improvements section](https://openbao.org/community/release-notes/2-6-0/#improvements-1) of [our release notes](https://
1openbao.org/community/release-notes/2-6-0/#v260) for information on all of them!\\n\\nStay tuned for more great features to come!\\n\\n## Looking ahead\\n\\nOpenBao v2.7.0 is already shaping up to be an exciting release! Control Groups landed early, allowing human-in-the-loop review of sensitive operations. External keys, a redesign of Vault Enterprise\'s Managed Keys, will allow for HSM- and KMS-backed key material in secret engines such as PKI and Transit. And support for PostgreSQL horizontal scalability will bring significant disaster recovery and operator experience improvements over the existing Raft support.\\n\\nInterested in getting involved? Take a look at our [roadmap](https://github.com/openbao/openbao/issues/1974), [fix a bug](https://github.com/openbao/openbao/issues/?q=is%3Aissue%20state%3Aopen%20label%3Abug), [help with documentation](https://github.com/openbao/openbao/issues/?q=is%3Aissue%20state%3Aopen%20label%3Adocs), [join our community calls](https://openbao.org/community/contributing/#community-calendar), [publicize the release](https://www.linkedin.com/company/openbao/posts), or join us on the [Linux Foundation\'s Zulip instance](https://
1openbao.org/community/contributing/#chat-server)!\\n\\n---\\n\\nThis post was originally authored by Alex Scheel and posted on [the OpenSSF blog](https://openssf.org/blog/2026/08/06/announcing-openbao-v2-6/)."},{"id":"flux-openbao-secrets-signatures","metadata":{"permalink":"/blog/flux-openbao-secrets-signatures","source":"@site/content/blog/2026-08-12-flux-secrets-and-signatures.mdx","title":"Flux and OpenBao: Secrets and Signatures","description":"This post shows off two Flux integrations with OpenBao: SOPS decryption through workload identity and sovereign OCI artifact signing with Cosign.","date":"2026-08-12T00:00:00.000Z","tags":[{"inline":true,"label":"integrations","permalink":"/blog/tags/integrations"},{"inline":true,"label":"fluxcd","permalink":"/blog/tags/fluxcd"},{"inline":true,"label":"cosign","permalink":"/blog/tags/cosign"}],"readingTime":9.58,"hasTruncateMarker":true,"authors":[{"name":"Matheus Pimenta","socials":{"github":"https://github.com/matheuscscp"},"imageURL":"https://avatars.githubusercontent.com/matheuscscp","key":"matheuscscp","page":null}
1,{"name":"Fabian Kammel","socials":{"github":"https://github.com/datosh"},"imageURL":"https://avatars.githubusercontent.com/datosh","key":"datosh","page":null},{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null},{"name":"Leigh Capili","socials":{"github":"https://github.com/stealthybox"},"imageURL":"https://avatars.githubusercontent.com/stealthybox","key":"stealthybox","page":null}],"frontMatter":{"title":"Flux and OpenBao: Secrets and Signatures","description":"This post shows off two Flux integrations with OpenBao: SOPS decryption through workload identity and sovereign OCI artifact signing with Cosign.","slug":"flux-openbao-secrets-signatures","authors":["matheuscscp","datosh","cipherboy","stealthybox"],"tags":["integrations","fluxcd","cosign"],"image":"https://raw.githubusercontent.com/fluxcd/website/881c45085313727bba31b4073859ee8c0377fa03/content/en/blog/2026-07-30-flux-openbao-secrets-signatures/featured-image.png"},"unlisted":false,"prevItem":{"title":"Announcing OpenBao v2.6!","permalink":"/blog/release-v2-6-0"},"nextItem":{"title":"OpenBao Features - Recursive Lists (SCAN) & Filtering","permalink":"/blog/features-recursive-list"}},"content":"import Head from \'@docusaurus/Head\';\\n\\n<Head>\\n <link rel=\\"canonical\\" href=\\"https://fluxcd.io/blog/2026/07/flux-openbao-secrets-signatures/\\" />\\n</Head>\\n\\nGitOps helps us declare our desired workloads, but how do we deal with and manage secrets? Additionally, as our fleet grows, we also blend artifacts and configuration from many\\ndifferent sources. How do we trust what we are running?\\n\\n[OpenBao](/) is an open source secrets and encryption\\nplatform under the [OpenSSF](https://openssf.org/). In this post we\'ll integrate OpenBao with [Flux](https://fluxcd.io) in two ways:\\n- kustomize-controller will decrypt SOPS-encrypted Secrets through OpenBao using **workload identity**, with no\\nstatic `BAO_TOKEN` or `VAULT_TOKEN` to bootstrap\\n- Cosign will sign OCI artifacts with a key held within OpenBao,\\nproducing signatures Flux can verify without any service\\noutside your infrastructure\\n\\nFor both integrations, we\'ll use two OpenBao features. The\\n[Transit secrets engine](/docs/secrets/transit/) performs\\nencrypt, decrypt, and sign operations without ever releasing the key\\nmaterial, acting as a\\n[Key Management System (KMS)](https://csrc.nist.gov/glossary/term/key_management_system),\\nand the Kubernetes and JWT auth methods let a workload trade its\\nKubernetes-issued ServiceAccount token for a short-lived OpenBao token, so\\nno long-lived credential has to exist on either the OpenBao or Kubernetes side.\\n\\n\\n\\n\x3c!-- truncate --\x3e\\n\\n## Configuring SOPS: GitOps secrets without a static token\\n\\nKeeping encrypted secrets in Git solves most of the secret-distribution\\nproblem: the ciphertext goes through the same pull requests and the same\\nreconciliation as the rest of your configuration. [SOPS](https://getsops.io/),\\na CNCF project, is the standard tool for this. It encrypts the values of a\\nfile with a data key, then asks a KMS to protect that data key; only the\\nsmall data key ever travels to the KMS. OpenBao is one of many supported\\nbackends that SOPS can use, and many teams rely on Flux\'s support for decrypting secrets with SOPS.\\n\\nBootstrapping secrets management is tricky though. The SOPS encryption key lives in OpenBao\'s\\nTransit engine, so Flux used to need a static `BAO_TOKEN` added in the cluster in order to\\nrequest decryption. Teams installing Flux would need to provision this bootstrap secret before using GitOps to manage secrets. Starting with Flux v2.9, that token is optional:\\nkustomize-controller can now directly authenticate to OpenBao with Kubernetes ServiceAccount tokens.\\n\\n### Step 1: Configure OpenBao for SOPS decryption\\n\\nFor our use-case, OpenBao needs a Transit key, a decrypt-only policy, and an auth role bound\\
1nto the kube ServiceAccount Flux will use. Both the \\"Kubernetes\\" and \\"JWT\\" auth\\nmethods within OpenBao work for this; with Kubernetes auth and the `flux-system/kustomize-controller`\\nServiceAccount, the setup is:\\n\\n```shell\\nbao secrets enable transit\\nbao write transit/keys/sops key_type=aes256-gcm96\\n\\nbao policy write flux_sops_decrypt - <<EOF\\npath \\"transit/decrypt/sops\\" {\\n capabilities = [\\"update\\"]\\n}\\nEOF\\n\\nbao auth enable kubernetes\\nbao write auth/kubernetes/config \\\\\\n kubernetes_host=https://kubernetes.example.com:6443 \\\\\\n [email protected] \\\\\\n [email protected]\\n\\nbao write auth/kubernetes/role/flux-system_kustomize-controller \\\\\\n bound_service_account_names=kustomize-controller \\\\\\n bound_service_account_namespaces=flux-system \\\\\\n audience=https://openbao.example.com:8200 \\\\\\n token_policies=flux_sops_decrypt \\\\\\n ttl=20m\\n```\\n\\nThe role name here follows Flux\'s `{namespace}_{name}` convention, and the\\n`audience` needs to match the OpenBao address that will show up in the SOPS\\nmetadata below. Note that `flux_sops_decrypt` only grants decryption; the\\ndeveloper or CI identity encrypting in Step 2 needs `update` on\\n`transit/encrypt/sops` instead. The\\n[Kubernetes auth](/docs/api/auth/kubernetes/) and\\n[JWT/OIDC auth](/docs/api/auth/jwt/) API docs cover the\\nOpenBao server-side options.\\n\\n### Step 2: Encrypt a Secret with OpenBao\\n\\nAfter authenticating to OpenBao, a developer or CI job encrypts a regular\\nKubernetes Secret with the Transit key:\\n\\n```shell\\nsops encrypt \\\\\\n --hc-vault-transit https://openbao.example.com:8200/v1/transit/keys/sops \\\\\\n --encrypted-regex \'^(data|stringData)$\' \\\\\\n secret.yaml > secret.enc.yaml\\n# These flag options can be defaulted in the repo with `.sops.yaml`\\n```\\n\\nSOPS calls `transit/encrypt/sops` on the user\'s behalf and writes out a\\nfile that is encrypted and safe to commit to Git:\\n\\n```yaml\\napiVersion: v1\\nkind: Secret\\nmetadata:\\n name: database\\n namespace: apps\\ntype: Opaque\\nstringData:\\n username: ENC[AES256_GCM,data:...,iv:...,tag:...,type:str]\\n password: ENC[AES256_GCM,data:...,iv:...,tag:...,type:str]\\nsops:\\n hc_vault:\\n - vault_address: https://openbao.example.com:8200\\n engine_path: transit\\n key_name: sops\\n created_at: \\"2026-07-14T12:00:00Z\\"\\n enc: vault:v1:...\\n encrypted_regex: ^(data|stringData)$\\n mac: ENC[AES256_GCM,data:...,iv:...,tag:...,type:str]\\n```\\n\\nThe plaintext values are replaced with ciphertext, and the `sops.hc_vault`\\nmetadata records which OpenBao instance and key can decrypt them.\\n\\n### Step 3: Configure kustomize-controller to use workload identity for OpenBao\\n\\nWhen Flux reconciles a file like this, kustomize-controller must ask\\nOpenBao to decrypt it. Instead of a static token, the controller gets an allowlist\\nof OpenBao instances and their JWT-backed login endpoints from a ConfigMap in the\\n`flux-system` namespace, set by the `--sops-vault-configmap` controller flag:\\n\\n```yaml\\n# data fields for a ConfigMap in the flux-system namespace\\ndata:\\n config.yaml: |\\n instances:\\n - address: https://openbao.example.com:8200\\n loginPath: auth/kubernetes/login\\n```\\n\\nDuring decryption, the OpenBao address in the SOPS metadata matches an\\nentry from this list. kustomize-controller requests a ServiceAccount token\\nwith that address as its audience and presents it at the login path, where\\nOpenBao matches it against the role from Step 1 and returns a short-lived\\ntoken. Flux uses that token to call the Transit engine and decrypt the\\nSecret. No static credential is needed anywhere for this decryption operation! We\'re leveraging Kubernetes\' native workload identity.\\n\\n### Step 4: Use a dedicated ServiceAccount for decryption\\n\\nBy default the exchange above uses kustomize-controller\'s own\\nServiceAccount. A Flux Kustomization can select a dedicated one instead:\\n\\n```yaml\\nspec:\\n decryption:\\n provider: sops\\n serviceAccountName: sops\\n```\\n\\nThis requires the `ObjectLevelWorkloadIdentity` feature gate to be enabled\\nin kustomize-controller. For a Kustomization in the `apps` namespace, the\\n`sops` ServiceAccount needs a matching `apps_sops` role in OpenBao,\\nconfigured with the same audience and policy as in Step 1. For more\\ndetails, see the\\n[Kustomization decryption documentation](https://fluxcd.io/flux/components/kustomize/kustomizations/#openbaovault-kubernetes-auth).\\n\\n## Cosign: Sovereign Software Signatures\\n\\nWe can use this KMS setup for more than application Secrets.\\n\\nFlux can verify the [Cosign](https://docs.sigstore.dev/) signature of an\\nOCI artifact before reconciling desired state from it. With a static public key, that\\nverification can be entirely local to the cluster: Flux checks the signature against the key\\nand forms no opinion about how or where the artifact was signed. It never\\ncontacts Fulcio, Rekor, or any other service outside the cluster and its container registry.\\n\\nThis makes a fully self-hosted signing chain possible: OpenBao holds the\\nsigning key, Cosign signs the artifact, the registry stores the signature,\\nand Flux verifies it. No public cloud KMS ever holds your key, and no\\npublic transparency log records your signing events. This is really attractive in regulated environments that prioritize data-sovereignty.\\n\\n```text\\nOpenBao Transit engine \u2192 Cosign \u2192 GHCR (artifact + signature) \u2192 Flux\\nholds the signing key signs stores signature verifies\\n```\\n\\nFlux also supports keyless verification: omit `.verify.secretRef` and Flux\\nmatches OIDC identities against Fulcio certificates and the Rekor\\ntransparency log. Keyless signing gives you short-lived signing identities and a\\npublic audit record, at the cost of depending on public Sigstore\\ninfrastru
1cture. Flux lets you choose this behavior per source; we use a static\\nkey in this post to show that key custody and rotation can stay fully under your responsibility.\\n\\nFor a fully reproducible setup, see the\\n[openbao-flux-demo](https://github.com/controlplaneio-openbao/openbao-flux-demo) on GitHub.\\nWe\'ll detail the steps quickly below.\\n\\n### Step 1: Generate the signing key in OpenBao\\n\\nOpenBao\'s Transit secrets engine is a cryptography-as-a-service backend: it holds key material and performs sign and verify operations on request. Cosign supports this natively. Let\'s use Cosign to generate the keypair through our `openbao://` KMS URI:\\n\\n```shell\\ncosign generate-key-pair --kms openbao://control-plane-demo\\n```\\n\\nThe private key is created inside OpenBao and never written to disk. Only\\n`cosign.pub` lands on the local filesystem; we\'ll configure Flux to use this public key.\\n\\nThe demo runs OpenBao in development mode with a root token to keep setup\\nshort. In production, you\'ll want to sign with a token scoped to just this key like so:\\n\\n```hcl\\npath \\"transit/keys/control-plane-demo\\" {\\n capabilities = [\\"read\\"]\\n}\\n\\npath \\"transit/sign/control-plane-demo\\" {\\n capabilities = [\\"update\\"]\\n}\\n```\\n\\n### Step 2: Push and sign the artifact by digest\\n\\nPackage the manifests as an OCI artifact and push them with the Flux CLI:\\n\\n```shell\\nflux push artifact oci://ghcr.io/controlplaneio-openbao/openbao-flux-demo-workload:latest \\\\\\n --path=./workload \\\\\\n --source=\\"https://github.com/controlplaneio-openbao/openbao-flux-demo\\" \\\\\\n --revision=\\"main@sha1:$(git rev-parse HEAD)\\"\\n```\\n\\nThen sign the pushed artifact by its digest. Passing `--tlog-upload=false`\\nkeeps the signature off the public Rekor log, so the signing event itself\\nnever becomes a public record:\\n\\n```shell\\ncosign sign --key openbao://control-plane-demo --tlog-upload=false \\\\\\n ghcr.io/controlplaneio-openbao/openbao-flux-demo-workload@sha256:...\\n```\\n\\nOpenBao performs the signing operation and the signature is stored in the\\nregistry alongside the artifact. One thing to watch out for: Cosign\\nauthenticates to the registry on its own and does not share credentials\\nwith `flux push artifact --creds`, so it needs a separate `cosign login`.\\n\\n### Step 3: Configure Flux to verify the artifact\\n\\nFlux only needs the public key. Create a Secret holding it and reference\\nthat Secret from the `OCIRepository`\'s `.spec.verify`. The demo creates the\\nSecret directly; in production you would commit the public key to Git (it\\nis not sensitive, but you can optionally encrypt it), then let Flux manage the Secret alongside your other manifests:\\n\\n```shell\\nkubectl -n flux-system create secret generic cosign-public-key \\\\\\n --from-file=cosign.pub=cosign.pub\\n```\\n\\n```yaml\\napiVersion: source.toolkit.fluxcd.io/v1\\nkind: OCIRepository\\nmetadata:\\n name: demo-workload\\n namespace: flux-system\\nspec:\\n interval: 5m\\n url: oci://ghcr.io/controlplaneio-openbao/openbao-flux-demo-workload\\n ref:\\n tag: latest\\n verify:\\n provider: cosign\\n secretRef:\\n name: cosign-public-key\\n```\\n\\nWhen the signature checks out, Flux records it on the source and only then\\napplies the manifests:\\n\\n```text\\nSourceVerified=True (Succeeded): verified signature of revision latest@sha256:\u2026\\n```\\n\\nThe whole sign & verify flow here only depends on our private infrastructure.\\nNo external services on the internet are needed, the signing key comes from our OpenBao instance, and the signature on the artifact proves that the desired state configuration was signed within our network.\\n\\n## Get Involved\\n\\nWe\'re really keen on helping folks adopt workload identity. In this demo Flux\\nauthenticates to OpenBao with short-lived ServiceAccount tokens instead of\\na bootstrap secret, and clusters only reconcile artifacts signed by secure and self-hosted key infrastructure.\\n\\nIf you run OpenBao and Flux together, we\'d like to hear how it goes. Talk\\nto us in the #flux channel on [CNCF Slack](https://slack.cncf.io/), or\\nbring your use-case to one of the meetings on our\\n[community page](https://fluxcd.io/community/).\\n\\n## References\\n\\n- [Flux Kustomization decryption with OpenBao via workload identity](https://fluxcd.io/flux/components/kustomize/kustomizations/#openbaovault-kubernetes-auth)\\n- [Flux OCIRepository verification with public keys](https://fluxcd.io/flux/components/source/ocirepositories/#public-keys-verification)\\n- [OpenBao Transit engine](/docs/api/secret/transit/)\\n- [Cosign key management and KMS providers](https://docs.sigstore.dev/cosign/key_management/overview/)\\n- [OpenBao Kubernetes auth method API docs](/docs/api/auth/kubernetes/)\\
1n- [OpenBao JWT/OIDC auth method API docs](/docs/api/auth/jwt/)\\n\\n---\\n\\nThis post was originally authored by Matheus Pimenta, Fabian Kammel, Alexander Scheel, and Leigh Capili and posted on [the FluxCD blog](https://fluxcd.io/blog/2026/07/flux-openbao-secrets-signatures/)."},{"id":"features-recursive-list","metadata":{"permalink":"/blog/features-recursive-list","source":"@site/content/blog/2026-08-06-recursive-list.md","title":"OpenBao Features - Recursive Lists (SCAN) & Filtering","description":"Blog series describing OpenBao\'s features. This episode focuses on recursive list support via the new SCAN keyword.","date":"2026-08-06T00:00:00.000Z","tags":[{"inline":true,"label":"features","permalink":"/blog/tags/features"},{"inline":true,"label":"list","permalink":"/blog/tags/list"},{"inline":true,"label":"technical","permalink":"/blog/tags/technical"}],"readingTime":4.7,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao Features - Recursive Lists (SCAN) & Filtering","description":"Blog series describing OpenBao\'s features. This episode focuses on recursive list support via the new SCAN keyword.","slug":"features-recursive-list","authors":"cipherboy","tags":["features","list","technical"]},"unlisted":false,"prevItem":{"title":"Flux and OpenBao: Secrets and Signatures","permalink":"/blog/flux-openbao-secrets-signatures"},"nextItem":{"title":"OpenBao Features - Declarative Plugins","permalink":"/blog/features-declarative-plugins"}},"content":"This is the fifth part of a [multi-part series on OpenBao\'s features](/blog/tags/features).\\n\\n[Last time](./2026-07-30-declarative-plugins.md) we talked about declarative\\nplugin configuration and how it made deploying and adopting plugins much\\neasier. With OCI-based distribution operators can deploy plugins with just a\\nfew configuration snippets, mirroring OpenTofu\'s approach.\\n\\nWe hinted at addressing two of the [most-requested features](https://github.com/hashicorp/vault/issues?q=is%3Aissue%20sort%3Areactions-desc)\\nin HashiCorp Vault: [recursive list support](https://github.com/hashicorp/vault/issues/5275)\\nand [filtering of list responses](https://github.com/hashicorp/vault/issues/5362).\\n\\nAs mentioned there [by Vault community members](https://github.com/hashicorp/vault/issues/5275#issuecomment-2920932325),\\nwe\'ve supported recursive lists [since\\nOpenBao v2.2.0](/community/release-notes/2-2-0/#220) and\\n[filtered lists since OpenBao v2.4.0](/community/release-notes/2-4-0/#240).\\nAnd, for any plugin developers out there, [we support it in our external plugin\\nSDK](https://pkg.go.dev/github.com/openbao/openbao/sdk/v2/logical#Operation)\\nincluding [storage helpers which should work on Vault\\nas well](https://pkg.go.dev/github.com/openbao/openbao/sdk/v2/logical#ScanView).\\n\\n:::tip[Question]\\n\\nWhat other places need recursive list support?\\n\\n[Reach out to us](https://github.com/openbao#contact) if we\'ve missed one!\\n\\n::::\\n\\n\x3c!-- truncate --\x3e\\n\\n## Overview\\n\\nOpenBao has always supported a custom HTTP verb, `LIST`, for listing entries\\nunder a path. This is also supported via the `?list=true` [query\\nparameter](/docs/api/#api-operations) on a regular `GET`-verb request, for use\\nwhen clients cannot support custom verbs.\\n\\nIn designing [recursive listing](/community/rfcs/scan-operation), we realized\\nmany endpoints (like [KVv2\'s list entries](/docs/api/secret/kv/kv-v2/#list-secrets))\\nmade sense as both `LIST` and `SCAN` operations. Rather than forcing authors\\nto implement a new endpoint design--for example, moving from a layout like\\n`LIST /secrets/metadata/:path` to `LIST /secrets/metadata-recursive/:path`--we\\nopted to introduce a new verb, `SCAN` for this. This allowed us to extend ACL\\npolicies to allow policy authors control over recursive lists without having\\nto investigate a plugin\'s layout.\\n\\nFor instance, the policy:\\n\\n```hcl\\npath \\"secrets/*\\" {\\n capabilities = [\\"read\\", \\"create\\", \\"update\\", \\"list\\", \\"patch\\", \\"delete\\"]\\n}\\n```\\n\\ngives users the ability to perform mostly cheap operations, while restricting\\ntheir ability to do recursive lists (scan operations). However, if they\\nalso add the scan o
1peration:\\n\\n```hcl\\npath \\"secrets/*\\" {\\n capabilities = [\\"read\\", \\"create\\", \\"update\\", \\"list\\", \\"patch\\", \\"scan\\", \\"delete\\"]\\n}\\n```\\n\\nthis would be more expensive and maybe should only be allowed on specific\\nsubdirectories within a KVv2 layout:\\n\\n```hcl\\npath \\"secrets/metadata/my-app/*\\" {\\n capabilities = [\\"read\\", \\"create\\", \\"update\\", \\"list\\", \\"patch\\", \\"scan\\", \\"delete\\"]\\n}\\n```\\n\\n## Usage\\n\\nAs we discussed in past blogs, OpenBao has support for both\\n[pagination](./2026-07-01-paginated-lists.md) and [transactional\\nstorage](2026-07-09-transactional-storage.md). When coupled with\\n`SCAN` support, this gives users a powerful consistency tool to inspect\\na large number of secrets at once. For instance, the API call:\\n\\n```\\nSCAN secrets/detailed-metadata/my-app\\n```\\n\\nwould return a list response with metadata about each secret as well. While\\nthis would usually be a 1+n operation in Vault (list all secret and then\\nfetch its metadata), OpenBao will return them in a single operation, with a\\ntransaction to ensure internal consistency of the results.\\n\\nThe same holds true for namespaces: `bao namespace list` will show all\\ntop-level children of the current namespace, but `bao namespace scan` will\\nrecurse and show children-of-children and the full hierarchy.\\n\\nOpenBao also supports the `scan` operation via the `bao scan` command or\\nin the [Go API via `client.Logical().Scan(...)`](https://pkg.go.dev/github.com/openbao/openbao/api/v2#Logical.Scan)\\nand related operations.\\n\\n## Security\\n\\nThis ties into another [commonly requested feature in HashiCorp\\nVault](https://github.com/hashicorp/vault/issues/5362): restricting [list (and\\nnow scans!)](/community/rfcs/filtering-list/) to entries which the user can view.\\n\\nIn OpenBao, we [implemented a policy keyword](/docs/concepts/policies/#filtering-list-or-scan-results),\\n`list_scan_response_keys_filter_path`, which takes a\\n[`text/template`](https://pkg.go.dev/text/template) expression for limiting\\nvisible results. Visible results are entries which (when templating is applied\\naccording to the filter path) have list access for entries ending in a `/` or\\nread access otherwise. This means the policy author must know the\\ncorresponding type of the plugin and where to map list entries to. For\\nexample in KVv2, one could either map entries in a list or scan to the data\\n(`<mount>/data/<entry>`) or metadata (`<mount>/metadata/<entry>`) paths.\\n\\nConsider an ACL policy like:\\n\\n```hcl\\n# Allow listing secrets broadly but limit to visible results (read or list):\\npath \\"secrets/metadata/*\\" {\\n capabilities = [\\"list\\", \\"scan\\"]\\n\\n # See also: https://openbao.org/docs/concepts/policies/#filtering-list-or-scan-results\\n list_scan_response_keys_filter_path = \\"{{ .path }}{{ .key }}\\"\\n}\\n\\n# Allow reading secrets and metadata in shared:\\npath \\"secrets/data/shared/*\\" {\\n capabilities = [\\"read\\"]\\n}\\n\\npath \\"secrets/metadata/shared/*\\" {\\n capabilities = [\\"read\\"]\\n}\\n\\n# But allow full access to a personal space.\\npath \\"secrets/data/personal/*\\" {\\n capabilities = [\\"read\\", \\"create\\", \\"update\\", \\"list\\", \\"patch\\", \\"scan\\", \\"delete\\"]\\n}\\n\\npath \\"secrets/metadata/personal/*\\" {\\n capabilities = [\\"read\\", \\"create\\", \\"update\\", \\"list\\", \\"patch\\", \\"scan\\", \\"delete\\"]\\n}\\n```\\n\\nIn this example, a call to the scan endpoint would show entries under `shared/`\\nand `personal/` but hide entries under `private/` due to the filtering on the\\nlist result.\\n\\nUse of `text/template` allows for advanced functionality like changing the path\\nas well; for instance, if metadata wasn\'t widely used but direct secret access\\nshould be the control, `list_scan_response_keys_filter_path` could be written\\nas:\\n\\n```json\\n{{ .path | replace \\"secrets/metadata/\\" \\"secrets/data/\\" }}{{ .key }}\\n```\\n\\nbecause the list and scan endpoints are under `/metadata/` and n
1ot `/data/`.\\n\\n## Looking ahead\\n\\nGoing forward, we\'ll likely consider supporting `Scan(...)` and\\n`ScanWithData(...)` as part of our formal storage interface, allowing easier\\nimplementation for plugins.\\n\\nTune in next time as we explore ACME-enabled TLS listeners!"},{"id":"features-declarative-plugins","metadata":{"permalink":"/blog/features-declarative-plugins","source":"@site/content/blog/2026-07-30-declarative-plugins.md","title":"OpenBao Features - Declarative Plugins","description":"Blog series describing OpenBao\'s features. This episode focuses on declarative plugin distribution and registration in OpenBao.","date":"2026-07-30T00:00:00.000Z","tags":[{"inline":true,"label":"features","permalink":"/blog/tags/features"},{"inline":true,"label":"plugins","permalink":"/blog/tags/plugins"},{"inline":true,"label":"technical","permalink":"/blog/tags/technical"}],"readingTime":5.89,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao Features - Declarative Plugins","description":"Blog series describing OpenBao\'s features. This episode focuses on declarative plugin distribution and registration in OpenBao.","slug":"features-declarative-plugins","authors":"cipherboy","tags":["features","plugins","technical"]},"unlisted":false,"prevItem":{"title":"OpenBao Features - Recursive Lists (SCAN) & Filtering","permalink":"/blog/features-recursive-list"},"nextItem":{"title":"Sustainable Secrets Management with OpenBao - Open Source@Siemens 2026","permalink":"/blog/karras-os-siemens-2026-talk"}},"content":"This is the fourth part of a [multi-part series on OpenBao\'s features](/blog/tags/features).\\n\\n[Last time](./2026-07-21-declarative-configuration.md) we talked about how to\\ndeclaratively configure audit devices and initialize OpenBao. We saw how this\\nmade integration of OpenBao in a wider ecosystem or product (such as\\n[EdgeX](2025-03-18-edgex-selects-openbao.md)) easier.\\n\\nLike the last part, this part focuses on the operator experience, but for\\nconsumption of OpenBao\'s plugins: auth methods, secrets engines, auto-unseal\\ndevices, and more.\\n\\nOur motivation here is to build towards a more [OpenTofu](https://opentofu.org/)-like,\\nextensible ecosystem. Easier consumption, [community-maintained\\nplugins](https://github.com/openbao/openbao-plugins), and a future plugin\\nregistry will lead to more developers writing plugins and expand the\\nusefulness of OpenBao for everyone.\\n\\n:::tip[Question]\\n\\nWhat integrations would you like OpenBao to have? How would you like to see\\nwriting plugins made easier?\\n\\n[Contact us](https://github.com/openbao#contact) to share your thoughts or\\ncontribute to the ecosystem!\\n\\n::::\\n\\n\x3c!-- truncate --\x3e\\n\\n## Overview\\n\\nNearly everything within OpenBao is pluggable. OpenBao supports several types of plugins currently:\\n\\n| Type | Description |\\n| :-------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\\n| **Auth** | Allow bringing sources of identity--JWTs, certificates, passwords--and exchanging them for OpenBao tokens. |\\n| **Secret** | Allow generating credentials (whether passwords for databases, PKI certificates, static secrets, and more) and protected through OpenBao\'s tokens and authorization policies. |\\n| **Database** | Implement database-specific logic for updating and managing access for use with the `database` dynamic secret engine. |\\n| **KMS** | Implement specialized interfaces for using HSM and KMS devices (such as YubiHSM or GCP CloudKMS) for auto-unseal (and external keys in the upcoming v2.7.0). |\\n\\nPlugins have tw
1o primary classifications:\\n\\n| Classification | Description |\\n| :------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\\n| **Builtin** | Distributed as part of the main `bao` binary artifact. No external process is started. |\\n| **External** | Distributed as stand-alone binaries, requiring installation and configuration to use. Spawns an external process (managed by the OpenBao server) to handle plugin requests. |\\n\\nFor example, [`secrets-pki`](/docs/secrets/pki) is a **builtin** **secret**\\nplugin, but [`secrets-aws`](https://github.com/openbao/openbao-plugins/releases?q=secrets-aws-&expanded=true)\\nis an **external** **secret** plugin. [`auth-aws`](https://github.com/openbao/openbao-plugins/releases?q=auth-aws-&expanded=true)\\nalso exists and is an **external** **auth** plugin.\\n\\n## Usage\\n\\nOpenBao since [v2.5.x](/community/release-notes/2-5-0/#v250) supported\\n[declarative plugin configuration](/docs/configuration/plugins/). Three\\nmandatory configuration [parameters](/docs/configuration/#parameters) are\\nrequired for these demos:\\n\\n```hcl\\n// Only plugins from the specified directory will be loaded. This helps\\n// to prevent arbitrary binaries from being executed and leading to\\n// generalized RCE.\\nplugin_directory = \\"/openbao/plugins\\"\\n\\n// Setting this allows the server process to automatically download new\\n// plugins if they\'re not registered. Otherwise OpenBao will not contact\\n// the internet by default. This will occur on all nodes (active and\\n// standby).\\nplugin_auto_download = true\\n\\n// Setting this allows automatic registration of the plugin into the\\n// plugin catalog. This is allows operators to immediately use the plugin\\n// without having to manually register it using API commands:\\n//\\n// https://openbao.org/docs/api/system/plugins-catalog/\\nplugin_auto_register = true\\n```\\n\\nWith that in mind, adding an external plugin is greatly simplified:\\n\\n```hcl\\n// Defines a new secret engine, named \\"aws\\".\\nplugin \\"secret\\" \\"aws\\" {\\n // ## Distribution Information ##\\n\\n // Image is the container registry\'s address. It is strongly recommended\\n // to pull from a trusted, local registry mirror instead of a public\\n // registry.\\n //\\n // See also: https://github.com/openbao/openbao-plugins/pkgs/container/openbao-plugin-secrets-aws/1056268559?tag=v0.3.1\\n image = \\"ghcr.io/openbao/openbao-plugin-secrets-aws\\"\\n\\n // The version of the plugin itself; must be a semantic version and also a\\n // tag on the above registry.\\n //\\n // See also: https://semver.org/\\n version = \\"v0.3.1\\"\\n\\n // Within the image, the path to the plugin binary. For OpenBao\'s\\n // community maintained plugins, this is the same as the plugin itself.\\n binary_name = \\"openbao-plugin-secrets-aws\\"\\n\\n // ## Execution Information ##\\n\\n // This contains the hash of the plugin binary and is required regardless\\n // of distribution mechanism.\\n //\\n // If the above registry were to change the tag to point at a different\\n // version of the image, this sha256sum prevents us from pulling an\\n // unexpected plugin binary.\\n sha256sum = \\"641ae1858c0f660b4c3761286d627e1dcfd33dc35e7c83eb81ca9050b5bdc6d8\\"\\n\\n // args = [ ... ] and env = [ ... ] are optional parameters if the plugin\\n // requires additional information.\\n}\\n```\\n\\n...and send a `SIGHUP` or restart the server. That\'s it! You should now see\\nmessages in the server logs like:\\n\\n```hcl\\n[INFO] plugins: starting OCI plugin downloading\\n[DEBUG] plugins: processing plugin: plugin=secret-aws url=ghcr.io/openbao/openbao-plugin-secrets-aws:v0.3.1 binary_name=openbao-plugin-secrets-aws\\n[INFO] plugins: downloading plugin from OCI registry: plugin=secret-aws url=ghcr.io/openbao/openbao-plugin-secrets-aws:v0.3.1\\n[DEBUG] plugins: local platform: plugin=secret-aws platform=linux/amd64\\n[DEBUG] plugins: extracting plugin from OCI image: plugin=secret-aws target=/openbao/plugins/.oci-cache/secret-aws/641ae185/openbao-plugin-secrets-aws binary=openbao-plugin-secrets-aws\\n[INFO] plugins: found plugin binary in OCI image: plugin=secret-aws entry=openbao-plugin-secrets-aws size=25161890\\n[DEBUG] plugins: successfully extracted plugin binary: plugin=secret-aws path=/openbao/plugins/.oci-cache/secret-aws/641ae185/openbao-plugin-secrets-aws size=25161890\\n[INFO] plugins: successfully downloaded and validated plugin: plugin=secret-aws cached_path=/openbao/plugins/.oci-cache/secret-aws/641ae185/openbao-plugin-secrets-aws symlink_path=/openbao/plugins/secret-aws-v0.3.1 hash=641ae1858c0f660b4c3761286d627e1dcfd33dc35e7c83eb81ca9050b5bdc6d8\\n[INFO] plugins: OCI plugin downloading completed\\n```\\n\\nIt will now show up in the plugin catalog:\\n\\n```shell\\n$ bao read -field=secret sys/plugins/catalog\\n[aws kubernetes kv ldap openldap pki rabbitmq ssh totp transit]\\n```\\n\\nand the plugin can be enabled:\\n\\n```shell\\n$ bao secrets enable -path team/creds/aws aws\\nSuccess! Enabled the aws secrets engine at: team/creds/aws/\\n```\\n\\nLooking at the storage layout, we see that the plugin was downloaded and\\nplaced in the plugin folder as requested:\\n\\n```shell\\n$ tree -alh plugins/\\n[ 100] plugins/\\n\u251C\u2500\u2500 [ 66] .oci-cache\\n\u2502\xa0\xa0 \u2514\u2500\u2500 [ 16] secret-aws\\n\u2502\xa0\xa0 \u2514\u2500\u2500 [ 52] 641ae185\\n\u2502\xa0\xa0 \u2514\u2500\u2500 [ 24M] aws\\n\u2514\u2500\u2500 [ 80] secret-aws-v0.3.1 -> .oci-cache/secret-aws/641ae185/aws\\n```\\n\\n:::info\\n\\nEven if you don\'t want to automatically download plugins as part of the server\\nprocess, you can invoke the standalone `bao plugin` CLI to perform downloads\\nand still benef
1it from declarative configuration and OCI-based plugin\\ndistribution:\\n\\n```\\n$ bao plugin init -config /openbao\\n[INFO] Plugin directory: /openbao/plugins\\n[INFO] Found 1 OCI plugin(s) in configuration\\n[INFO] downloading plugin from OCI registry: plugin=secret-aws url=ghcr.io/openbao/openbao-plugin-secrets-aws:v0.3.1\\n[INFO] found plugin binary in OCI image: plugin=secret-aws entry=openbao-plugin-secrets-aws size=25161890\\n[INFO] successfully downloaded and validated plugin: plugin=secret-aws cached_path=/openbao/plugins/.oci-cache/secret-aws/641ae185/openbao-plugin-secrets-aws symlink_path=/openbao/plugins/secret-aws-v0.3.1 hash=641ae1858c0f660b4c3761286d627e1dcfd33dc35e7c83eb81ca9050b5bdc6d8\\n```\\n\\n:::\\n\\nThis pattern applies for secret, auth, and database plugins. When using kms\\nplugins, note that the plugin will not show up in the plugin catalog (shown\\nabove) but will be usable at startup:\\n\\n```hcl\\nplugin \\"kms\\" \\"pkcs11\\" {\\n image = \\"ghcr.io/openbao/openbao-plugin-kms-pkcs11\\"\\n version = \\"v0.1.0\\"\\n binary_name = \\"openbao-plugin-kms-pkcs11\\"\\n sha256sum = \\"55245882727535579e710672f0eae1bcdddc846006db857baaa6e09e33d40faf\\"\\n}\\n\\nseal \\"pkcs11\\" {\\n lib = \\"/usr/lib64/softhsm/libsofthsm.so\\"\\n token_label = \\"OpenBao\\"\\n pin = \\"4321\\"\\n key_label = \\"bao-root-key-rsa\\"\\n}\\n```\\n\\n## Next steps\\n\\nCheck our [updated documentation on plugins](/docs/next/plugins) and\\n[configuration reference](/docs/next/configuration/plugins).\\n\\nTune in next time for a post on recursive listing, one of HashiCorp Vault\'s\\n[most requested features](https://github.com/hashicorp/vault/issues/5275)."},{"id":"karras-os-siemens-2026-talk","metadata":{"permalink":"/blog/karras-os-siemens-2026-talk","source":"@site/content/blog/2026-07-27-karras-oss-siemens-2026-talk.md","title":"Sustainable Secrets Management with OpenBao - Open Source@Siemens 2026","description":"Blog of Michael\'s talk at Open Source @ Siemens 2026, diving into OpenBao\'s origins and why it is the sustainable choice.","date":"2026-07-27T00:00:00.000Z","tags":[{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"conferences","permalink":"/blog/tags/conferences"},{"inline":true,"label":"talks","permalink":"/blog/tags/talks"}],"readingTime":9.8,"hasTruncateMarker":true,"authors":[{"name":"Michael Hofer","socials":{"github":"https://github.com/karras","linkedin":"https://www.linkedin.com/in/secretz/"},"imageURL":"https://www.secretz.io/hofi.jpg","key":"karras","page":null}],"frontMatter":{"title":"Sustainable Secrets Management with OpenBao - Open Source@Siemens 2026","description":"Blog of Michael\'s talk at Open Source @ Siemens 2026, diving into OpenBao\'s origins and why it is the sustainable choice.","slug":"karras-os-siemens-2026-talk","authors":"karras","tags":["community","conferences","talks"]},"unlisted":false,"prevItem":{"title":"OpenBao Features - Declarative Plugins","permalink":"/blog/features-declarative-plugins"},"nextItem":{"title":"OpenBao Features - Declarative Configuration","permalink":"/blog/features-declarative-configuration"}},"content":"Slides and content from Michael\'s talk at Open Source @ Siemens 2026, diving\\ninto OpenBao\'s origins and why it is the sustainable choice.\\n\\nFor a video, see Siemens\' [official YouTube channel](https://www.youtube.com/watch?v=hPBT-kSS-68).\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-01.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWelcome everyone to my talk on OpenBao and sustainable secrets management! I\'m\\nMichael \\"Hofi\\" Hofer, CTO at Adfinis and Chair of the OpenBao Technical\\nSteering Committee (TSC).\\n\\nIt\'s fantastic to be back here in Zug for Open Source @ Siemens - for me\\npersonally, this event is always an annual highlight. Huge thanks to the\\nSiemens crew for organizing such a great event! Every year it gets better, and\\nthis time we even have romantic ambient lighting to go with it. I\'m already\\nlooking forward to next year.\\n\\nAlso, a quick shout-out to Jan and Pasquale for the [overview on\\nCIP](https://www.youtube.com/watch?v=R87uGvXzK7g) earlier. It\'s really cool to\\nsee a neighboring Linux Foundation project in action.\\n\\nToday I want to share how we can ensure secrets management remains open,\\ncommunity-driven, and sustainable for decades to come.\\n\\n\x3c!-- truncate --\x3e\\n\\n---\\n\\n### What is Secrets Management?\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-02.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nBefore we jump into OpenBao itself, let\'s briefly step back: what do we\\nactually mean when we talk about *secrets management*?\\n\\nLooking around the room, I know most of you have strong technical backgrounds,\\nso the core concept isn\'t new. It\'s the daily practice of protecting and\\nintegrating all the secrets your machine workloads need to function - API\\ntokens, TLS certificates, credential pairs, and client secrets.\\n\\nNotice I said *machine workloads*. We don\'t focus on human passwords here;\\nthose belong in a proper password manager. But for machine identities, the bar\\nis high: your secrets management solution needs to be super secure and highly\\navailable. But just as importantly, it has to be flexible and\\ndeveloper-friendly. Our main audie
1nce consists of engineering teams who just\\nwant a solution that works without getting in their way.\\n\\n---\\n\\n### Why is Secrets Management relevant for you?\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-03.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nIn my day-to-day conversations with community members and technicial teams, the\\nreasons to invest in secrets management usually boil down to three main\\ndrivers:\\n\\nFirst, **cybersecurity and risk mitigation**. We\'ve all seen secrets sprawl -\\nstatic database credentials or Kubernetes tokens committed into repos and never\\nrotated. If you come back to an environment three years later and find the\\nexact same root password sitting on every VM, that\'s a problem. Compliance\\nregulations like the Cyber Resilience Act (CRA) and audit flags are also paying\\ninto that.\\n\\nSecond, **efficiency**. Nobody wants to get an X.509 certificate delivered via\\nemail or pasted into a Slack channel, forcing you to become a manual secrets\\nmanager yourself when you\'d rather be writing code.\\n\\nAnd third, **saving money**. Many proprietary cybersecurity products on the\\nmarket carry immense license fees, making cost predictability a massive\\nheadache.\\n\\n---\\n\\n### Challenges in the Secrets Management ecosystem\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-04.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nLooking at secrets management today, technical teams want modern,\\nwell-integrated platforms, while organizations need data sovereignty because\\nthese systems hold their crown jewels.\\n\\nYet, proprietary vendors often force what we call an **\\"Architecture by\\nLicense.\\"** You design your secrets management platform according to a\\ncontract, instead of your actual needs to avoid exploding license costs.\\n\\nHow many of you have had a developer ask to onboard a new pipeline or\\nKubernetes cluster, only to be told: *\\"Sorry, we don\'t have the budget for\\nthose additional licenses this year\\"*? It forces us to ask: Is there no\\nsustainable, open alternative left?\\n\\n---\\n\\n### OpenBao is the answer\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-05.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWell, of course there is - and that\'s why OpenBao is here!\\n\\n---\\n\\n### What is OpenBao?\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-06.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nSo, what is OpenBao? At its core, OpenBao is a modern, open source secrets\\nmanagement solution designed to handle the full spectrum of security needs:\\n\\n* **Static and Dynamic Secrets:** From moving static KV keys into a central\\n store to generating short-lived database credentials or cloud identities that\\n are automatically revoked.\\n\\n* **PKI & Certificate Management:** Replacing manual certificate workflows with\\n automated internal CAs and ACME integration.\\n\\n* **Key Management & Cryptography-as-a-Service:** Offloading encryption,\\n decryption, and signing operations directly to OpenBao APIs so your\\n applications don\'t have to handle raw keys.\\n\\nOpenBao is hosted under the **Linux Foundation (OpenSSF)**. It was forked from\\nHashiCorp Vault in late 2023 under the open MPL-2.0 license.\\n\\nNow, here\'s an interesting side story: does anyone know who was one of the main\\ndriving forces and founders behind initiating the fork?\\n\\nIt was actually IBM. They were heavily invested in the Open Horizon project\\nunder LF Edge, which relied on Vault. When Vault\'s license changed, they helped\\nlaunch and drive the fork under the Linux Foundation (right around the same\\ntime Terraform was forked into OpenTofu).\\n\\nUnfortunately, those IBM colleagues got pulled out of the OpenBao project when\\nIBM acquired HashiCorp a few months later. Though we\'d welcome them back\\nanytime.\\n\\nMost importantly, it remains **largely API compatible**. If you have a tool,\\nclient library, or solution with a \\"Vault supported\\" stamp, there is a very\\nhigh chance it will work with OpenBao out of the box.\\n\\n---\\n\\n### By and for the community\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-07.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nOne thing I want to make clear: OpenBao is not a single-vendor project. It\'s\\nbuilt by and for the community.\\n\\nWe have a fantastic, healthy maintainer base of roughly 15 to 20 co-maintainers\\nactively working on the project every single day. A massive **thank you** to\\nall of them and to our wider community!\\n\\nOur governance is completely transparent, managed by the Technical Steering\\nCommittee (T
1SC) under the OpenSSF. We have colleagues from (alphabetically)\\n**Adfinis, ControlPlane, GitLab, IOTech, SAP, WALLIX**, and independent\\nmaintainers driving the project forward together. Multi-vendor governance is\\nessential for true open source sustainability. It ensures no single vendor can\\npull the rug out or change the rules on you later.\\n\\n---\\n\\n### The OpenBao ecosystem is growing!\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-08.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nA few months ago, we decided to launch an [ecosystem page](/ecosystem/) on\\nopenbao.org to show who is using, adopting, and integrating with OpenBao. Since\\nthen, the ecosystem page has taken off faster than we anticipated!\\n\\nWe have ISVs, HSM manufacturers, cloud service providers, and security vendors\\nlike Nitrokey, NVIDIA, Crypto4A, OVHcloud, Utimaco, Percona, Securosys,\\nSigstore, and others listed. Seeing this real-world adoption proves that\\nOpenBao is rapidly becoming a trusted standard for production workloads.\\n\\n---\\n\\n### Commercial sustainability\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-09.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nNow, allow me a quick word on how Adfinis, for example, makes this sustainable\\nfrom a business perspective. We heard about open source budgets from the\\nprevious talk by the CIP project, and at Adfinis we faced the same question:\\nHow do we fund full-time upstream development on OpenBao for years to come?\\n\\nOur answer was productizing **Secretz Enterprise** - an enterprise subscription\\nproviding 24/7 enterprise support, software assurance, and continuous\\ndevelopment for OpenBao.\\n\\nWe built this model to be **vendor lock-in free** while mitigating the \\"Success\\nTax\\", where you get penalized for growth with a per-identity pricing model. If\\na customer ever cancels their subscription, their production clusters keep\\nrunning without a hitch. There are no artificially gated features, no\\nper-identity limits, and no hidden license keys. Everything we build goes\\nupstream first.\\n\\nIn a similar manner [other vendors in the ecosystem](/ecosystem/vendors/) are\\nalso invested in order to build a sustainable business model to supp
1ort OpenBao\\nin the long run.\\n\\n---\\n\\n### Recent and unique features\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-10.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nOpenBao isn\'t just maintaining a fork. We are actively adding features that our\\ncommunity has been asking for, including:\\n\\n* **PostgreSQL Storage Backend:** Offering PostgreSQL as a storage option\\n alongside the widely adopted Raft backend for organizations with established\\n database footprints.\\n\\n* **Declarative Operator Workflows:** Introducing declarative\\n self-initialization, declarative plugin distribution via OCI images, and\\n declarative audit devices to make deployments as smooth as possible.\\n\\n* **Namespaces:** Shipping multi-tenant namespace isolation out of the box.\\n\\n* **Horizontal Read Scalability:** Released in version 2.5, allowing standby\\n nodes to serve read requests directly, paving the way for many more such\\n capabilities.\\n\\n---\\n\\n### Project and development direction\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-11.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWhere are we heading next? We divide our priorities into two streams:\\n\\n**Project Direction:** We are focused on community growth, moving from the\\nOpenSSF Sandbox to the Incubation stage, launching our Marketing Working Group,\\nand filling documentation gaps with user and operator guides.\\n\\n**Development Direction:** Just to name a few of the many additional cool\\ncapabilities, including External Keys, Seal Pluginization and Per-Namespace\\nSealing (shipped in 2.6), or a dedicated provider for the External Secrets\\nOperator.\\n\\n---\\n\\n### How to contribute and join the community?\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-12.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nIf you\'re interested in checking out OpenBao or want to get involved, we would\\nlove to have you! Head over to\\n[openbao.org/community](/community):\\n\\n* **Join the Chat:** Jump into our Zulip chat channel or drop into our open\\n community calls.\\n* **GitHub:** Open issues, start discussions, or send PRs on\\n [github.com/openbao/openbao](https://github.com/openbao/openbao).\\n* **Working Groups:** Participate in dedicated groups around development,\\n security, or marketing.\\n* **Get Listed:** If your organization is using OpenBao, open a PR to add your\\n logo to our ecosystem page!\\n\\n---\\n\\n### Contribute and win!\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-13.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWe don\'t quite have a fancy contributor store like GitLab just yet, but we do\\nhave some cool swag to give away!\\n\\nThe first three people who submit **3 mergeable pull requests** adhering to our\\ncontribution guidelines can email me at `[email protected]` to claim\\ntheir prize:\\n\\n* **1st Place:** OpenBao Bricks Kit\\n* **2nd Place:** OpenBao T-Shirt\\n* **3rd Place:** OpenBao Stickers\\n\\n*Note: Existing project and TSC members are excluded to keep it fair for new\\ncontributors!*\\n\\n---\\n\\n### Let\'s collaborate!\\n\\
1n<object type=\\"image/svg+xml\\" data=\\"/img/talks/karras-os-siemens-2026/Sustainable-Secrets-Management-Slide-14.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nThank you so much for your time today, and thanks again to Siemens for hosting\\nOpenBao here in Zug!"},{"id":"features-declarative-configuration","metadata":{"permalink":"/blog/features-declarative-configuration","source":"@site/content/blog/2026-07-21-declarative-configuration.md","title":"OpenBao Features - Declarative Configuration","description":"Blog series describing OpenBao\'s features. This episode focuses on declarative configuration of OpenBao.","date":"2026-07-21T00:00:00.000Z","tags":[{"inline":true,"label":"features","permalink":"/blog/tags/features"},{"inline":true,"label":"configuration","permalink":"/blog/tags/configuration"},{"inline":true,"label":"technical","permalink":"/blog/tags/technical"}],"readingTime":4.7,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao Features - Declarative Configuration","description":"Blog series describing OpenBao\'s features. This episode focuses on declarative configuration of OpenBao.","slug":"features-declarative-configuration","authors":"cipherboy","tags":["features","configuration","technical"]},"unlisted":false,"prevItem":{"title":"Sustainable Secrets Management with OpenBao - Open Source@Siemens 2026","permalink":"/blog/karras-os-siemens-2026-talk"},"nextItem":{"title":"OpenBao Features - Transactional Storage","permalink":"/blog/features-transactional-storage"}},"content":"This is the third part of a [multi-part series on OpenBao\'s features](/blog/tags/features).\\n\\nIn the past few parts, we talked about low-level technical features that\\nOpenBao core maintainers and plugin authors can take advantage of to make\\nsecrets management safer and more scalable.\\n\\nThis part focuses on something that applies to operators of OpenBao: better\\noperator experience for initial configuration. We focus on one question:\\n\\n:::tip[Question]\\n\\n**How can we make initial OpenBao deployment easier and more reproducible?**\\n\\n:::\\n\\n\x3c!-- truncate --\x3e\\n\\nThe answer lies in [declarative self-initialization](/docs/configuration/self-init/)\\nand [declarative audit device creation](/docs/configuration/audit).\\n\\nThese features [available since OpenBao v2.4.0](/community/release-notes/2-4-0/#features)\\nallow operators to define the state of OpenBao prior to deploying it.\\n\\n## Audit Devices\\n\\nSensitive programs like Vault and OpenBao should always have audit logs.\\nIdeally it would be hard to not them set up without audit logs, or at least,\\nmake it very hard to do so.\\n\\nHowever, the API model of Vault made this difficult originally:\\n\\n1. Operators would call [`sys/init`](/docs/api/system/init/) to create seal\\n information and return a root token.\\n2. Operators would then have to call [`sys/audit`](/docs/api/system/audit/) to\\n create an audit device.\\n\\nIn the meantime, they\'d want to be configuring OpenBao: creating auth mounts,\\npolicies, secret engines, and the like. Perhaps this was fully automated, like\\nin OpenTofu, and it would be hard to [guarantee a strict\\nordering](https://opentofu.org/docs/internals/graph/#walking-the-graph), due\\nto inherent parallelism.\\n\\nMotivating us to solve this was one of the few [remote code execution\\nvulnerabilities (RCEs)](https://discuss.hashicorp.com/t/hcsec-2025-14-privileged-vault-operator-may-execute-code-on-the-underlying-host/76033)\\nin Vault: audit device configuration frequently interacted with the broader\\nenvironment, including potentially in ways that lead to RCEs. While HashiCorp\\nopted just to [patch one small hole](https://developer.hashicorp.com/vault/docs/configuration#allow_audit_log_prefixing),\\nwe opted to reimagine how audit device configuration could be controlled by\\nconfiguration owners.\\n\\nThus [declarative audit devices](/community/rfcs/config-audit-devices/) were\\nborn.\\n\\nHere, system operators--those with privileged access to the underlying\\nconfiguration and broader execution environment--can define audit devices\\nthrough configuration files, reloading them on `SIGHUP`. These look like\\nthe following:\\n\\n```hcl\\naudit \\"file\\" \\"to-stdout\\" {\\n description = \\"Write audit information to standard output.\\"\\n options {\\n file_path = \\"stdout\\"\\n }\\n}\\n```\\n\\nWhile writing to `stdout` doesn\'t matter as much, consider the implications\\nwhen writing to [network devices](/docs/audit/socket/): operators can\\n[disable API-driven creation](/docs/configuration/#parameters) by setting\\n`unsafe_allow_api_audit_creation = false` (the default) and ensure that a\\nleaked admin token doesn\'t result in secrets being exfiltrated to an attacker\\nover the network.\\n\\nAs an added bonus, every single request is now audited after initialization,\\nincluding any declarative self-initialization requests that we\'ll see below.\\n\\n## Self-Initialization\\n\\nGoing hand-in-hand with configuration-driven audit devices is [declarative\\nself-initialization](/docs/configuration/self-init/).\\n\\nHere, operators define requests that they want executed when OpenBao first starts up:\\n\\n```hcl\\ninitialize \\"authentication\\" {\\n request \\"mount-userpass\\" {\\n path = \\"sys/auth/userpass\\"\\n operation = \\"create\\"\\n data = {\\n type = \\"userpass\\"\\n description = \\"Administrative access to OpenBao.\\"\\n }\\n }\\n\\n request \\"create-user\\" {\\n path = \\"auth/userpass/users/admin\\"\\n operation = \\"create\\"\\n data = {\\n password = {\\n eval_source = \\"env\\"\\n eval_type = \\"string\\"\\n\\n // Read the initial administrator password from an\\n // environment variable.\\n env_var = \\"INITIAL_ADMIN_PASSWORD\\"\\n require_present = true\\n }\\n\\n token_policies = [\\"admin\\"]\\n }\\n }\\n\\n request \\"create-policy\\" {\\n operation = \\"create\\"\\n path = \\"sys/policies/acl/admin\\"\\n data = {\\n policy = <<EOP\\n\\npath \\"*\\" {\\n capabilities = [\\"create\\", \\"update\\", \\"patch\\", \\"read\\", \\"delete\\", \\"list\\", \\"scan\\", \\"sudo\\"]\\n}\\n\\nEOP\\n\\n }\\n }\\n}
1\\n```\\n\\nThis would:\\n\\n1. Create a new `auth/userpass` mount,\\n2. Create an administrative user, and\\n3. Create a highly privileged policy for that user.\\n\\nWhile this may not look that different from an operator running commands\\nmanually, consider the implications for OpenBao as a building block of some\\nlarger system. This system would need:\\n\\n- A source of identity, to tie OpenBao into;\\n- A KMS or similar auto-unseal device (including `static`) to automate\\n unseal;\\n- A service orchestration layer (whether systemd unit files or Kubernetes),\\n- A system to manage day one OpenBao operations.\\n\\nGiven those exist, operators can provision the initial state fully\\ndeclaratively.\\n\\nOpenBao gives operators several tools for interacting in the form of [dynamic\\ndata source](/docs/concepts/profiles/#value-types-and-dynamic-data-sources).\\nThese can be [environment variables](/docs/concepts/profiles/#env-source):\\n\\n```hcl\\npassword = {\\n eval_source = \\"env\\"\\n eval_type = \\"string\\"\\n\\n // Read the initial administrator password from an\\n // environment variable.\\n env_var = \\"INITIAL_ADMIN_PASSWORD\\"\\n require_present = true\\n}\\n```\\n\\nor [files](/docs/concepts/profiles/#file-source):\\n\\n```hcl\\npolicy = {\\n eval_source = \\"file\\"\\n eval_type = \\"string\\"\\n\\n path = \\"/path/to/admin-policy.hcl\\"\\n}\\n```\\n\\nOpenBao also supports chaining from the value of past\\n[requests](/docs/concepts/profiles/#request-source) or\\n[responses](/docs/concepts/profiles/#response-source):\\n\\n```hcl\\nentity_id = {\\n eval_source = \\"response\\"\\n eval_type = \\"string\\"\\n\\n initialize_name = \\"identity\\"\\n response_name = \\"entity\\"\\n field_selector = [\\"data\\", \\"id\\"]\\n}\\n```\\n\\nand can do [CEL](/docs/concepts/profiles/#cel-source) or\\n[`text/template`](/docs/concepts/profiles/#template-source)\\nbased templating:\\n\\n```hcl\\npath = {\\n eval_source = \\"template\\"\\n eval_type = \\"string\\"\\n\\n template = \\"auth/userpass/users/{{ .input.username }}\\"\\n}\\n```\\n\\nThis allows construction of fairly advanced configurations and interactions\\nwith nearly every subsystem regardless of complexity.\\n\\nThink of self-initialization like the building block of a fully reproducible\\nenvironment: operators define the minimal configuration necessary to stand\\nup OpenBao and then systems like [OpenTofu](https://opentofu.org) can take\\nover from there.\\n\\n:::info\\n\\nSelf-initialization has three design limitations:\\n\\n1. It is intentionally only run on first startup. This ensures that an\\n attacker can\'t later modify the configuration and grant themselves\\n privileged access.\\n2. Only a single node should be started to do self-initialization; parallel\\n self-initialization is not supported and may fail or lead to split-brained\\n Raft cluster
1s.\\n3. Operators need to be running auto-unseal so that initial startup is fully\\n automatic.\\n\\n:::"},{"id":"features-transactional-storage","metadata":{"permalink":"/blog/features-transactional-storage","source":"@site/content/blog/2026-07-09-transactional-storage.md","title":"OpenBao Features - Transactional Storage","description":"Blog series describing OpenBao\'s features. This episode focuses on transactional storage.","date":"2026-07-09T00:00:00.000Z","tags":[{"inline":true,"label":"features","permalink":"/blog/tags/features"},{"inline":true,"label":"storage","permalink":"/blog/tags/storage"},{"inline":true,"label":"technical","permalink":"/blog/tags/technical"}],"readingTime":5.58,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao Features - Transactional Storage","description":"Blog series describing OpenBao\'s features. This episode focuses on transactional storage.","slug":"features-transactional-storage","authors":"cipherboy","tags":["features","storage","technical"]},"unlisted":false,"prevItem":{"title":"OpenBao Features - Declarative Configuration","permalink":"/blog/features-declarative-configuration"},"nextItem":{"title":"Dreaming of a Better User Experience for Shamir\'s","permalink":"/blog/better-shamir-ux"}},"content":"This is second part of a [multi-part series on OpenBao\'s features](/blog/tags/features).\\n\\nToday we focus on [transactional storage](/community/rfcs/transactions/). While\\nthe [earlier](./2024-10-16-transactions.md) blog [posts](./2024-10-27-transaction-details.md)\\nfocused on the what and how of transactions in Raft, this post will focus on\\nthe measurable impact of transactions in OpenBao and their lack in Vault. We\\nwill demo some possible ways of creating snapshots which cannot restore and\\nare not consistent on Vault and show how we used transactions to achieve\\nconsistency on OpenBao.\\n\\n\x3c!-- truncate --\x3e\\n\\n## Historical context\\n\\nRecall from [last week\'s post](./2026-07-01-paginated-lists.md) that our\\nstarting storage interface was rather limited:\\n\\n```go\\n// Storage is the way that logical backends are able read/write data.\\ntype Storage interface {\\n List(context.Context, prefix string) (entries []string, err error)\\n Get(context.Context, path string) (entry *StorageEntry, err error)\\n Put(context.Context, entry *StorageEntry) error\\n Delete(context.Context, path string) error\\n}\\n```\\n\\n(from [`fork-point:sdk/logical/storage.go`](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/sdk/logical/storage.go#L31-L37)).\\n\\nAlso included in the storage model of the fork, though implemented in only\\na few backends (Raft, CockroachDB, Consul, FoundationDB, and Spanner) was a\\nbasic batch application mechanism:\\n\\n```go\\n// TxnEntry is an operation that takes atomically as part of\\n// a transactional update. Only supported by Transactional backends.\\ntype TxnEntry struct {\\n\\tOperation Operation\\n\\tEntry *Entry\\n}\\n\\n...\\n\\n// Transactional is an optional interface for backends that\\n// support doing transactional updates of multiple keys. This is\\n// required for some features such as replication.\\ntype Transactional interface {\\n\\t// The function to run a transaction\\n\\tTransaction(context.Context, []*TxnEntry) error\\n}\\n```\\n\\n(from [`fork-point:sdk/physical/transactions.go`](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/sdk/physical/transactions.go#L13-L30)).\\n\\nNotably, from the [implementation of\\n`physical.GenericTransactionHandler`](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/sdk/physical/transactions.go#L46-L153),\\nwe see that this was not an implementation of check-and-set semantics: `LIST`\\noperations are entirely ignored, any `GET` operations are dispatched ahead of\\nany writes, and while a rollback log is created and entries read before\\nissuing any writes, they are not compared against any sent writes. This makes\\nbatch application rather unsafe if used incorrectly: if a (distributed) lock\\nmechanism or other exclusive ownership semantic does not exist, multiple\\nin-flight transactions can write to the same storage entr
1ies. This may produce\\nunexpected results.\\n\\nLuckily, this mechanism was not exposed at the logical level, hiding its use\\nwithin Core and all auth and secret plugins, preventing its misuse.\\n\\nFrom [commit messages](https://github.com/openbao/openbao/commit/c1cf97adac5c53301727623a74b828a5f12592cf)\\nwe can guess this mechanism was an internal implementation detail of the\\n[proprietary Vault Enterprise Performance Replication\\nmode](https://support.hashicorp.com/hc/en-us/articles/20457140183443-Replication-Overview-and-Merkle-Sync-Loop-Analyses)\\nand thus not relevant to improving snapshot consistency.\\n\\nOpenBao instead moved to a much more powerful interactive transaction model:\\n\\n```go\\n\\n// Transactional is an optional interface for backends that support\\n// interactive (mixed code & statement) transactions in a similar\\n// style as Go\'s Database paradigm. This is equivalent to\\n// physical.Transactional, not the earlier, one-shot version of the\\n// interface.\\ntype Transactional interface {\\n\\t// This function allows the creation of a new interactive transaction\\n\\t// handle, only supporting read operations. Attempts to perform write\\n\\t// operations (Put(...) or Delete(...)) will err.\\n\\tBeginReadOnlyTx(ctx context.Context) (txn Transaction, err error)\\n\\n\\t// This function allows the creation of a new interactive transaction\\n\\t// handle, supporting read/write transactions. In some cases, the\\n\\t// underlying physical storage backend cannot handle parallel read/write\\n\\t// transactions.\\n\\tBeginTx(ctx context.Context) (txn Transaction, err error)\\n}\\n\\n// Transaction is an interactive transactional interface: backend storage\\n// operations can be performed, and when finished, Commit or Rollback can\\n// be called. When a read-only transaction is created, write calls (Put(...)\\n// and Delete(...)) will err out.\\ntype Transaction interface {\\n\\tStorage\\n\\n\\t// Commit a transaction; this is equivalent to Rollback on a read-only\\n\\t// transaction. Either Commit or Rollback must be called to release\\n\\t// resources.\\n\\tCommit(ctx context.Context) error\\n\\n\\t// Rollback a transaction, preventing any changes from being persisted.\\n\\t// Either Commit or Rollback must be called to release resources.\\n\\tRollback(ctx context.Context) error\\n}\\n```\\n\\n(from [`main:sdk/logical/storage_transactions.go`](https://github.com/openbao/openbao/blob/main/sdk/logical/storage_transactions.go#L10-L43)).\\n\\nCallers of this API can perform arbitrary storage operations interleaved with\\nnon-storage calls and have consistency amongst all of them. This is\\nimplemented in both supported storage backends, Raft and PostgreSQL.\\n\\n## Reproducers\\n\\nLooking at plugin code in our [`fork-point` tag](https://github.com/openbao/openbao/tree/fork-point/builtin),\\nany series of multi-write flow could potentially be affected by a snapshot\\nconsistency issue. However, to be affected by snapshot consistency issues,\\nthe server needs to assume that either both writes succeeded or neither did.\\n\\n### PKI\\n\\nOne such is in the PKI engine.\\n\\nWhen creating a new issuer via `<mount>/root/generate/internal`, the [following\\nstorage operations](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/builtin/logical/pki/path_root.go#L256-L320)\\nare performed:\\n\\n 1. `config/key/<id>`, to [store the new root CA\'s key](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/builtin/logical/pki/storage.go#L437-L440)\\n 2. `config/keys`, to [store the new default issuer config](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/builtin/logical/pki/storage.go#L509-L511)\\n 3. `config/issuer/<id>`, to [import the new root CA\'s certificate](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/builtin/logical/pki/storage.go#L907-L911)\\n 4. `config/issuers`, to [store the new default issuer config](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/builtin/logical/pki/storage.go#L920-L922)\\n 5. `crls/<id>`, to [store the initial empty CRL](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/builtin/logical/pki/crl_util.go#L2197-L2203)\\n\\nNotably consistency between storage operations 3 and 4 are the crucial:\\nfailure to store the initial issuer\'s identifier as default will mean that\\nAPI compatibility with older Vault versions (and many third-party\\napplications) which are not aware of multi-issuer features is broken. This\\nwill cause the API to return an error like:\\n\\n```\\nerr=Error making API request.\\n\\nURL: GET http://localhost:8200/v1/058a0c0f-2dc3-a4a3-2e22-b00811700bac/issuer/default\\nCode: 500. Errors:\\n\\n* 1 error occurred:\\n * no default issuer currently configured\\n\\nresp=<nil>\\n```\\n\\nwhich will persist on all operations until an operator manually creates an\\n[association between the generated issuer and the\\n`default`](/docs/api/secret/pki/#set-issuers-configuration). Similar issues\\ncould occur whenever an issuer is rotated; the key could be persisted but the\\nsigning certificate could be dropped from the backup.\\n\\nNotably, PKI\'s usage here would be a poor fit for check-and-set semantics:\\ncomposability of `importKey` and `importIssuer` into `writeCaBundle` would\\nbe difficult to achieve while retaining transactional properties. This is why\\nthe stronger interactive transaction model is better for OpenBao\'s use case,\\neven though it limits the theoretical storage backends one could implement\\nas not every potential storage engine (like S3) implements interactive\\ntransactions."},{"id":"better-shamir-ux","metadata":{"permalink":"/blog/better-shamir-ux","source":"@site/content/blog/2026-07-07-better-initialization.md","title":"Dreaming of a Better User Experience for Shamir\'s","description":"A blog outlining what a better user experience for Shamir\'s might look like and what advantages it might have for OpenBao.","date":"2026-07-07T00:00:00.000Z","tags":[{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"conferences","permalink":"/blog/tags/conferences"},{"inline":true,"label":"vision","permalink":"/blog/tags/vision"}],"readingTime":4.58,"hasTruncateMarker":true,"authors":[{"name":"Alex Sc
1heel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Dreaming of a Better User Experience for Shamir\'s","description":"A blog outlining what a better user experience for Shamir\'s might look like and what advantages it might have for OpenBao.","slug":"better-shamir-ux","authors":"cipherboy","tags":["community","conferences","vision"]},"unlisted":false,"prevItem":{"title":"OpenBao Features - Transactional Storage","permalink":"/blog/features-transactional-storage"},"nextItem":{"title":"OpenBao Features - Paginated Lists","permalink":"/blog/features-paginated-lists"}},"content":"At [Open Source Summit North America](./2026-06-17-cipherboy-oss-na-26-talk.md),\\nI met [Dr. Justin Cappos](https://engineering.nyu.edu/faculty/justin-cappos),\\nprofessor at NYU and major OpenSSF contributor and working group lead, and\\nseveral of his students.\\n\\nAlong with broader discussions of how OpenBao and [gittuf](https://gittuf.dev/)\\nmight integrate, we talked about Shamir\'s unsealing and its fundamental\\nproblem: it is a side-effecting process with high-entropy results. You can\\nwrap it around a common dictionary, hex or base64 encoding, or other means to\\nmake the key shares more consumable by humans, but the results will still be\\ncomplex and hard to input and store.\\n\\nThe problems I\'m looking for a scheme to solve are two fold:\\n\\n\x3c!-- truncate --\x3e\\n\\n1. Secure storage of Shamir shares are hard. It effectively relies on another,\\n externally secure system (whether physical or digital) to safely store. In\\n [emergency scenarios](/community/rfcs/emergency-seal/), this is fine, but\\n if Shamir\'s is in regular use, this can be cumbersome depending on whether\\n systems are air gapped or similar.\\n2. We can\'t easily use [declarative self-initialization](/docs/configuration/self-init/)\\n as we required a side-effect-less initialization.\\n\\n### On Shamir\'s\\n\\nWhile I will spare people too much math, some initial context on why this is\\nnon-trivial with Shamir\'s is important. For a conceptual model, think of\\n[Shamir\'s secret sharing](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing)\\nas using polynomial equations:\\n\\n```\\ns + a_1 x_1 + a_2 x_2^2 + a_3 x_3 ^ 3 + ...\\n```\\n\\nBy convention, the secret is embedded as the constant term of this polynomial,\\nwith constants (`a_1 ... a_n`) being randomly chosen values. To allow for a\\nthreshold of `n+1` shares required to recover, a `n` degree polynomial must\\nbe chosen. For two share recovery, a linear equation is used; for three shares\\nto recover, a quadratic, &c. This is because while `n+1` `(x, y)` points\\nuniquely describe a `n`-degree polynomial, `n` shares leaks no information:\\nnearly any possible constant term could fall out.\\n\\nThis gives Shamir\'s secret sharing a useful property: _information theoretic\\nsecurity_.\\n\\n:::info\\n\\nThe above is a simplification: left to the reader are discussions about\\nencoding secrets and the frequent implementation over finite fields rather\\nthan the real numbers. Make sure to always use cryptographically secure\\nrandom number generators and do not roll your own crypto!\\n\\nOpenBao has moved [its Shamir\'s implementation to\\n`sdk/`](https://pkg.go.dev/github.com/openbao/openbao/sdk/v2/helper/shamir)\\nso that others may consume it.\\n\\n:::\\n\\n### Requirements\\n\\nCappos proposed a model for Shamir\'s that worked by masking password hashes\\nwith the Shamir shares (via an xor); but in our context, we would mask Shamir\\nshares with password hashes. Supposing such a scheme could exist, we\'d care\\nabout the following properties:\\n\\n1. It isn\'t _much_ more computationally expensive. Shamir\'s is easy to verify:\\n combining the pieces and performing a decryption of the root key using the\\n recovered AES-GCM key is relatively cheap.\\n2. It doesn\'t have side effects: we can\'t require the owner to know which Shamir\\n share a given password maps to.\\n3. It retains the core cryptographic properties of Shamir\'s when used in our\\n barrier encryption scheme: thresholds, arbitrary share ordering, &c must\\n all be retained.\\n4. Storage of shares must be safe in plaintext. Because this is the root of\\n our cryptography, we don\'t have any other secure storage mechanism\\n available yet.\\n5. Hinted at above, but passwords and shares must be independent. While the\\n security of the scheme as a whole will be dictated by the combined entropy\\n of the (threshold-determined) weakest passwords, we can put system limits\\n on their construction. Passwords shouldn\'t derive into shares and thus have\\n unex
1pected determinism: we\'d want strictly independent root keys to allow\\n for rotation under the same passwords.\\n\\n:::info\\n\\n_Aside_: Actual security depends on the details of this scheme and what\\ndefinition of \\"isn\'t much more computationally expensive\\" is used. Certain\\nvariants provide more security (sum of weakest passwords) whereas others are\\nfaster to verify at the cost of less security (strength of nth weakest\\npassword). Balancing that trade-off will probably depend on use cases; if\\nyou\'re interested, feel free to [reach out](https://github.com/openbao#contact)\\nto us and mention the blog!\\n\\n:::\\n\\n### Results\\n\\nAssuming such a scheme existed, this would give us a great way to extend our\\nside-effect free [declarative self-initialization](/docs/configuration/self-init)\\nto Shamir\'s seal mechanisms:\\n\\n1. Operators would establish configuration like they do for auto-unseal\\n devices and namespace sealing, specifying the number of generated shares\\n and thresholds. This could perhaps be denoted via a new seal type,\\n `shamir-pass` or similar.\\n2. Operators could optionally specify minimum password complexity rules using\\n our existing [password policies](/docs/concepts/password-policies), which\\n support validating against existing passwords.\\n3. We have two options for how initialization could go:\\n\\n - We could either immediately initialize, requiring operators to\\n authenticate with any provisioned authentication provider and then\\n subsequently only allow initialization requests (blocking broader\\n requests to the system) to provide the required passwords until\\n concluded.\\n\\n - Or, we could delay self-initialization until sufficient passwords have\\n been provided, following the existing (unauthenticated) initialization\\n or rotation patterns.\\n\\n Notably, neither of these two approaches would yield keys to the API\\n callers which must be stored.\\n\\nWithin [namespace sealing](/community/rfcs/namespace-sealing), we would\\nalready have an authenticated rotation mechanism and be able to reuse that\\nfor initialization.\\n\\nFrom an unseal perspective, this also makes it easier for air-gapped operators\\nwanting to use Shamir\'s to type and unseal OpenBao."},{"id":"features-paginated-lists","metadata":{"permalink":"/blog/features-paginated-lists","source":"@site/content/blog/2026-07-01-paginated-lists.md","title":"OpenBao Features - Paginated Lists","description":"Blog series describing OpenBao\'s features. This episode focuses on paginated lists.","date":"2026-07-01T00:00:00.000Z","tags":[{"inline":true,"label":"features","permalink":"/blog/tags/features"},{"inline":true,"label":"storage","permalink":"/blog/tags/storage"},{"inline":true,"label":"technical","permalink":"/blog/tags/technical"}],"readingTime":3.81,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao Features - Paginated Lists","description":"Blog series describing OpenBao\'s features. This episode focuses on paginated lists.","slug":"features-paginated-lists","authors":"cipherboy","tags":["features","storage","technical"]},"unlisted":false,"prevItem":{"title":"Dreaming of a Better User Experience for Shamir\'s","permalink":"/blog/better-shamir-ux"},"nextItem":{"title":"OpenBao: Horizontally Scaling Secrets Management - OSSNA 2026","permalink":"/blog/cipherboy-ossna-26-talk"}},"content":"This is the start of a [multi-part series on OpenBao\'s features](/blog/tags/features).\\n\\nNearly every single networked interface returning a list of results supports\\nsubsets. SQL supports the [`LIMIT` and `OFFSET` keywords](https://www.postgresql.org/docs/current/queries-limit.html),\\nalong with a rich language for filtering returned results. Google Cloud KMS\\nAPIs [supports `pageSize`, yielding a `nextPageToken`](https://docs.cloud.google.com/kms/docs/reference/rest/v1/projects.locations.keyRings/list?rep_location=global),\\nfor iterating over multiple pages of results.\\n\\nMany resources in Vault and OpenBao return lists:\\n[KVv2 secrets](/docs/api/secret/kv/kv-v2/#list-secrets),\\n[PKI\'s certificate lists](/docs/api/secret/pki/#list-certificates),\\n[SSH\'s roles](/docs/api/secret/ssh/#list-roles), and more.\\n\\nPaginated lists were shipped [in OpenBao v2.0.0](/community/release-notes/2-0-0/#200)\\nas our very first feature in our very first release!\\n\\nSo, why doesn\'t Vault support paginated lists?\\n\\n\x3c!-- truncate --\x3e\\n\\nThe answer lies in its historical great-common-denominator storage interface:\\n\\n```go\\n// Storage is the way that logical backends are able read/write data.\\ntype Storage interface {\\n List(context.Context, prefix string) (entries []string, err error)\\n Get(context.Context, path string) (entry *StorageEntry, err error)\\n Put(context.Context, entry *StorageEntry
1) error\\n Delete(context.Context, path string) error\\n}\\n```\\n\\n(from [`fork-point:sdk/logical/storage.go`](https://github.com/openbao/openbao/blob/8993802145833ab01d49c6070d787a9eccb81546/sdk/logical/storage.go#L31-L37)).\\n\\nIn supporting [over twenty different storage\\nbackends](https://github.com/openbao/openbao/tree/fork-point/physical),\\nVault had to support a common core of simple APIs over all potential storage\\nbackends. This meant keeping `Storage.List(...)` to a simple get-all-results\\nlist operation. If LIST APIs were to limit results, this would mean they\'d\\nstill have to fetch them all from storage and only limit them in memory before\\nsending to the client.\\n\\nEarly in OpenBao\'s history, the [decision was made](/community/policies/plugins/)\\nto remove all but the Raft storage backend. This made it possible to iterate\\non our storage model. Concretely, [paginated lists](/community/rfcs/paginated-lists/)\\nand [transactional storage](/community/rfcs/transactions/) (to be discussed\\nanother time!) came out of that. As we [re-introduced](/community/rfcs/postgresql/)\\nstorage backends [like PostgreSQL](/docs/configuration/storage/postgresql/),\\nwe made sure to include the improvements we\'ve made to the storage API from\\nthe start.\\n\\nOpenBao\'s storage interface now looks like:\\n\\n```go\\n// Storage is the way that logical backends are able read/write data.\\ntype Storage interface {\\n\\tList(context.Context, prefix string) (entries []string, err error)\\n\\tListPage(context.Context, prefix string, after string, limit int) (entries []string, err error)\\n\\tGet(context.Context, path string) (entry *StorageEntry, err error)\\n\\tPut(context.Context, entry *StorageEntry) error\\n\\tDelete(context.Context, path string) error\\n}\\n```\\n\\n(from [`v2.5.5:sdk/logical/storage.go`](https://github.com/openbao/openbao/blob/v2.5.5/sdk/logical/storage.go#L35-L42))\\n\\nmeaning that API handlers can now fetch only a subset of results.\\n\\nThis follows a SQL-like interface:\\n\\n```go\\nfunc (b *RaftBackend) ListPage(ctx context.Context, prefix string, after string, limit int) ([]string, error) {\\n\\t// ... implementation elided ...\\n}\\n```\\n\\n(from [`v2.5.5:physical/raft/raft.go`](https://github.com/openbao/openbao/blob/v2.5.5/physical/raft/raft.go#L1716))\\n\\ntaking the new parameters `after` and `limit`. These are:\\n\\n- `after`: an optional entry to begin listing after for pagination; not required to\\n exist in the list results.\\n- `limit`: an optional number of entries to return; defaults to all entries\\n when set to a non-positive number.\\n\\nWe suggest plugin authors pass these through on all API endpoints to the\\nunderlying storage calls.\\n\\nFor plugin authors who build against OpenBao\'s SDK but wish to have\\ncompatibility with HashiCorp Vault, we\'ve [stubbed the\\nimplementation](https://github.com/openbao/openbao/blob/v2.5.5/sdk/plugin/grpc_storage.go#L92-L115),\\nmeaning you can safely expose and use a paginated list API and support it\\non both server implementations.\\n\\nIn addition, use of paginated lists has lead to improvements like\\n[#678](https://github.com/openbao/openbao/pull/678) by Fatima Patel, to\\nuse pagination during PKI\'s tidy operations. In the past, tidy operations\\ncould consume a lot of memory if a large number of PKI mounts contained a\\nlarge number of stored leaf certificates. We exposed a new `page_size` option\\n(defaulting to 1000) to limit the number of certificate serial numbers in\\nmemory during a single PKI tidy operation.\\n\\nBy enforcing this with [`pagination_limit`](/docs/concepts/policies/#limiting-pagination)\\nin an ACL policy, operators can now ensure that clients use pagination and set\\nmaximum result set sizes going forward.\\n\\nIn short, OpenBao aligns with long-standing industry expectations for\\nexpensive list calls and operators have more control with OpenBao than with\\nVault for managing the performance impact of these types of API requests.\\n\\nTune in next time for a discussion on [transactional storage](./2024-10-16-transactions.md)!"},{"id":"cipherboy-ossna-26-talk","metadata":{"permalink":"/blog/cipherboy-ossna-26-talk","source":"@site/content/blog/2026-06-17-cipherboy-oss-na-26-talk.md","title":"OpenBao: Horizontally Scaling Secrets Management - OSSNA 2026","description":"Blog of Alex\'s talk at Open Source Summit North America 2026, describing the horizontal scalability features of OpenBao.","date":"2026-06-17T00:00:00.000Z","tags":[{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"conferences","permalink":"/blog/tags/conferences"},{"inline":true,"label":"talks","permalink":"/blog/tags/talks"}],"readingTime":20.54,"hasTruncateMarker":true,"authors":[{"name":"Alex Sc
1heel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao: Horizontally Scaling Secrets Management - OSSNA 2026","description":"Blog of Alex\'s talk at Open Source Summit North America 2026, describing the horizontal scalability features of OpenBao.","slug":"cipherboy-ossna-26-talk","authors":"cipherboy","tags":["community","conferences","talks"]},"unlisted":false,"prevItem":{"title":"OpenBao Features - Paginated Lists","permalink":"/blog/features-paginated-lists"},"nextItem":{"title":"Improved Horizontal Scalability","permalink":"/blog/improved-horizontal-scalability"}},"content":"Slides and content from Alex\'s Open Source Summit NA 2026 talk, describing the horizontal scalability features of OpenBao.\\n\\nFor a video, see the Linux Foundation\'s [official YouTube channel](https://www.youtube.com/watch?v=vNsEAmNPwH0).\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-01.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWelcome everyone to my talk on OpenBao and how we added horizontal scalability to the project. I\'m Alex Scheel, Head of OpenBao Development at ControlPlane, a long time member of the OpenBao TSC, and chair of the OpenBao Development Working Group.\\n\\nI\'ve been fortunate to have a hand in the development of OpenBao since nearly the beginning of the project, and before that, at HashiCorp\'s Vault CryptoSec team.\\n\\nIf, like me, you were wishing you could get out for a post-lunch walk, thank you for staying, but we\'ll have to settle for some photos of Minneapolis I\'ve sprinkled through the presentation. And thank you all for visiting Minnesota, whether from near or far!\\n\\n\x3c!-- truncate --\x3e\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-02.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nFirst, what is OpenBao?\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-03.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nOpenBao is an open-source secrets manager, featuring everything from static and dynamic secrets to PKI and key management services. We have integrations with everything from External Secrets Operator and Cert Manager to OpenTofu, SOPS, and cosign.\\n\\nWe also have a growing ecosystem; check out our ecosystem page afterwards and if you\'re an adopter, integrator, or supporter, consider adding your logo!\\n\\nOpenBao is an OpenSSF Sandbox project and is licensed under the MPLv2.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-04.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nIf this sounds familiar, it should be!\\n\\nOpenBao is the open-source continuation of HashiCorp Vault, started in late 2023 after the relicensing to the non-OSI BUSL license.\\n\\nWe aim to keep API compatibility for client applications, but to improve the operator and developer experience. Towards that goal, we\'ve landed several Vault Enterprise features--such as horizontal scalability, which this talk focuses on--but also many original improvements like declarative self-initialization, storage-level improvements for better performance and snapshot consistency, and landing in our next release, things like an externally pluggable KMS interface, operator-defined workflows built on the existing profile engine, and per-namespace (per-tenant) barrier encryption keys with optional namespace sealing support.\\n\\n(This photo is taken from the Mill Ruins park, facing the Mill City Museum which is hosting tonight\'s drone show.)\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-05.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>
1\\n\\nOpenBao\'s top-level governance body, its technical steering committee (TSC), is currently made up of the following companies: my employer, ControlPlane, a seat jointly occupied by SAP and Liquid Reply who SAP has contracted with to contribute to our community, Adfinis, Wallix, IOTech, and GitLab.\\n\\nOur governance is openly documented in the project\u2019s main repository. We have tracks for leadership (in the form of the TSC), for developers (in the form of the Dev Working Group and its many sub-working groups), and maintainership for those interested in contributing to reviews on the project. We\u2019ve also started a marketing working group if talking about OpenBao or its usage is more your style.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-06.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nIn my early 2025 talk at FOSDEM (which you can see on the OpenBao blog archive), I mentioned that I had hoped to grow a community around OpenBao of companies that make money supporting it, just like Kubernetes. Not long after that talk, both Adfinis and SAP stepped up and started contributing to the community. This March, I joined ControlPlane to further that mission as well, leading our efforts to commercialize support and maintenance of the project. You can read more about that on ControlPlane\'s blog.\\n\\nControlPlane employs maintainers for FluxCD, is a contributor to several CNCF and OpenSSF efforts, and focuses on a highly regulated customer base like banks and government entities.\\n\\nI\'m happy to report for anyone following along, the OpenBao community is healthy, growing, and my hopes have been answered! Though of course, we always welcome more contributions of any sort!\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-07.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nThis now brings us to what we\'re here to discuss. Horizontal Scalability, and the journey to support it.\\n\\nI\'ll focus on three parts mostly:\\n\\n1. What building blocks did the fork have? What were we starting with?\\n\\n2. How did we support Raft in OpenBao v2.5.0? What challenges did we face along the way?\\n\\n3. How will we support PostgreSQL and more going forward? How will this improve the operator experience?\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-08.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWe started by trying to understand what we inherited from HashiCorp Vault.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-09.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nMost importantly, we started with a highly available (though, not horizontally scalable!) base. In OpenBao as it stood before this feature, we had data replication already taken care of. We supported two HA storage backends (Integrated Storage aka Raft and PostgreSQL),\\n\\nOpenBao and HashiCorp Vault have a single active node which can perform write operations; this is a limitation of the Raft protocol and used as a design decision elsewhere.\\n\\nIn Vault Community Edition which we inherited, probably for open-core feature differentiation with Vault Enterprise, HashiCorp only supported cold standbys: these were \\"unsealed\\" and ready to take over if the active node went down, but could only forward requests to it and did not do any processing locally.\\n\\nIn OpenBao v2.5.0, we wanted to land horizontal scalability, which meant we needed a way for these cold standby nodes to serve read requests. They still wouldn\'t handle write requests, but they could help alleviate some of the load from the single active node, depending on the user\'s workloads.\\n\\nAnd, of course, we had a constraint that we wanted to behave similarly to Vault Enterprise\'s Performance Standby node types.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-10.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nHow does Vault Enterprise behave? And what is a read request?\\n\\nVault Enterprise roughly defines a read request as something that doesn\'t cause any storage writes.\\n\\nConfusingly, this has a very loose association with HTTP verbs. For instance, the Certificate Revocation List (CRL) rotation endpoint in the PKI engine incurs a storage write (the CRL itself), but uses the GET verb. More obviously, login, e.g., via the `userpass` authentication method, causes several storage writes.\\n\\nBoth of these, if they come into a read-enabled standby, would be forwarded.\\n\\nFor the types of requests that will be handled by a standby node, a KVv1 secret read operation would be handled locally; it is guaranteed to not have any write operations. Most KVv2 operations will not have any writes either. Additionally, some POST operations will be strictly handled locally: if a PKI engine\'s role is configured not to store leaf certificates, the issuance endpoint could be handled on the read-enabled standby node.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-11.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nFrom an operational standpoint it is now clear what we want to achieve, though we have a few quirks we need to work out with our storage backends. How do we handle invalidation of caching that occurs n
1aturally?\\n\\nFor integrated storage, each OpenBao node becomes its own storage backend. It uses the Raft consensus protocol to handle replication of data between all nodes. This protocol is based on a leadership election process, which requires an odd number of voting nodes to be consistent. Each write sent by the leader is confirmed by another vote.\\n\\nThis write confirmation forms the basis of the write-ahead-log (WAL) mechanism. This WAL mechanism contains enough information about every storage write, which gives us an easy way to invalidate cached storage entries.\\n\\nOn PostgreSQL however, any number of nodes can be used as they all race to acquire a lock stored in the database. While PostgreSQL handles the data replication for us--giving us a M:N OpenBao service to database node decoupling--it doesn\'t by default provide enough information for invalidation on standby nodes. But more on that later.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-12.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nLooking at the existing code base, there\'s a few hints we have on how invalidation is supposed to work.\\n\\nThis is a snippet of code from the PKI secrets engine. There are two parts I bolded:\\n\\n1. When we invalidate, we\'re given a context and the path of the storage entry that changed. We don\'t get the contents of the entry or if it was updated or deleted.\\n2. Similarly, we see that we shouldn\'t block too long: this code path spins off a goroutine to handle the update in the background. Other code paths in this function just flip the value of an atomic boolean for the next API request to adjust.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-13.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nPutting this together, we learned that cache invalidation must be definite, operating on specific keys which were invalidated; it isn\'t TTL based. There must be some storage-path-based routing engine that dispatches invalidations from the storage layer, through core, to the plugin.\\n\\nAnd, because invalidation must be in some hot path (in the case of Raft, we know it must be part of the WAL application process), we\'ve learned that handling the invalidation synchronously isn\'t good for performance, so we should execute it asynchronously.\\n\\n(This photo is features the Third Avenue bridge, looking back on downtown Minneapolis.)\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-14.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nMoving right along, it was time to implement this.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-15.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nThe design idea roughly looked something like this:\\n\\n1. We started by assuming we could just load all core subsystems and plugins on the standby node.\\n2. We allowed requests to come in, rather than automatically forwarding them. After this, we built a mechanism to conditionally forward requests when a storage write occurred.\\n3. And we built a cache invalidation layer based on the earlier analysis of our existing code, and a mechanism for routing storage paths to the owning subsystem.\\n\\nSimple, right?\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-16.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nStarting from the existing HA code, it took a lot of work to refactor core to (correctly!) bring up the standby node as a reader. While conceptually simple, we found that we had some partial state (from being non-read-enabled) that we need to make sure we reset. And we found we needed a new post-unseal strategy which did not incur any writes and didn\'t load any subsystems which only performed writes, such as automatic barrier key rotation or starting the request forwarding server (which standbys connect to).\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-17.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWhen processing read requests, we changed the request routing to now only conditionally forward the request (if the node was still a cold standby), and default to processing requests. This necessitated a second forward pass if the request could not be handled locally. Notably, a failed write request would result in no state, as the standby nodes cannot write to their underlying storage.\\n\\nIn creating this, we needed to refactor how requests were processed at the http layer: previously we only read the body once, either to forward it or to process it on the active node. However, as we now consumed the body twice, we built a way of spooling the request body and resetting back to the initial state on forward.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-18.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nThe contract between OpenBao\'s core and its storage engines is conceptually simple: the storage engine just needs to tell us when a write occurs, so we can define a callback approach for this in the base `sdk/physical` interface.\\n\\nThis was implemented in the Integrated Storage (Raft) backend.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-19.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nHowever, the actual dispatch of invalidations is more complex.\\n\\nWe take pending c
1allbacks from the storage engine and queue them into an asynchronous fairshare job queue, sharded by expected namespace. This prevents one particularly noisy tenant from starving all other tenants, at the cost of not necessarily guaranteeing relative order of writes across namespaces.\\n\\nThis job then handles the storage-level routing of written path to owning backend. Some backends are privileged, like the core of OpenBao itself, and can take longer to process invalidations. For instance, the mount table explicitly reloads the new entry, potentially spinning off a new external plugin process so that it is ready before the next inbound request. Requests routed to an sandboxed plugin, e.g., PKI, get processed with a short, 2 second context to enforce strict asynchronous behaviors and use of their own background worker contexts.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-20.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nThe result of all this is that standby nodes now process read requests. In the chart on the left, before adding read request handling, only a single service process was consuming CPU. Now, on the right, all three service processes share this developer\'s machine and consume CPU processing requests.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-21.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWhen it comes to running in a real, multi-node deployment, the impact becomes more clear. Where there was more contention for certain locks, the OpenBao v2.4.4 cluster\'s single active node was able to handle far fewer PKI certificate issuance operations. The other two standbys were completely idle.\\n\\nIn OpenBao v2.5.1, all three nodes were able to service requests, decreasing lock contention, giving us higher throughput and lower latency.\\n\\nYou can read more about this in Philipp\'s entry on the OpenBao blog.\\n\\n\\nOf course, things don\'t always go as planned. For some example of bugs we\'ve fixed:\\n\\n1. When loading current state, we didn\'t pass through standby vs active node status to all places that needed it. This meant that, when upgrading a legacy non-transactional storage type to a read-enabled standby (say, in a direct migration from OpenBao v2.0.0 to v2.5.0), we\'d fail to start up.\\n\\n2. Certain types of specially handled requests (like root token generation) were not correctly forwarded to the active node as they were outside the regular request routing mechanism. This will be fixed in 2.5.4 coming this week.\\n\\n3. But most of our bugs have been in the largest section of new code: invalidation routing. While plugin\'s invalidation logic was already present in Vault Community Edition, most of the core invalidation logic was presumably hidden in Vault Enterprise and wasn\'t part of our code base. This is the most difficult to test as it requires understanding and validating each individual subsystem.\\n\\nMostly these come from community bug reports -- and some patches have even come from drive-by contributors, which is always appreciated.\\n\\n\\nThe release series containing horizontal read scalability, OpenBao 2.5.x, was shipped at the start of the year, and so may already be running on your systems!\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-22.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nBefore we move on, I\'d like to thank again the contributors to this feature: Fatima was the 2025 OpenBao Mentee sponsored by Adfinis, Philipp, an Adfinis employee, was her mentor and also contributed to the design and implementation, and I helped with implementation, reviews, and debugging.\\n\\n(This photo was taken by my wife, Katherine Mayo, one winter, looking from the iconic Stone Arch bridge back on the city.)\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-23.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nYou might be thinking... wait! ... you mentioned that the invalidation hook was implemented in the Raft backend, but what happened to the PostgreSQL backend?\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-24.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWell, it turns out it is slightly more complicated to implement.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-25.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWe started by thinking that maybe the built-in `LISTEN`+`NOTIFY` support in PostgreSQL would allow a sort of storage-level inter-process communication (IPC) which w
1ould save us from implementing it at the node-level.\\n\\nAmong other challenges, it turns out that these events may be silently dropped if OpenBao disconnects and reconnects through a proxy such as `pgbouncer`. This makes it unreliable for our use in invalidations.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-26.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nPostgreSQL has a WAL as well; why can\'t we use it? For starters, database operators would need to configure PostgreSQL to have a higher WAL verbosity level (`wal_level=logical`). Additionally, OpenBao cannot subscribe to the WAL on read-replica PostgreSQL nodes; only the PostgreSQL primary sends WAL events. This means having two database connections rather than just one on standby nodes.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-27.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWe thought about adding either a last modification time to the existing OpenBao schema, which loses the ability to easily detect deletes, or adding a new WAL subscription table. The latter puts garbage collection pressure on the database and has some of the same peer longevity problems as the PostgreSQL WAL implementation. We\'d need to manually remove processed invalidations and keep track of which invalidations were seen by which live standby nodes.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-28.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nWhat about moving to a more standard TTL-based expiration? The biggest issues here are that OpenBao relies on invalidating lists--that is, knowing when a new entry was created--and that invalidating certain entries, such as the mount table, is rather expensive as it holds a few global locks that block incoming requests. This means more refactoring would be needed before we could adopt this approach.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-29.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nUltimately, we settled on implementing a GRPC stream-based notification mechanism, using our existing GRPC connection for forwarding requests. The standby will subscribe to the leader for invalidations, wait for the initial index to ensure it is caught up, and then begin processing both read requests and invalidations from the active. The active will send the expected index at which the data was written, which the secondary can then wait for.\\n\\nRight now, OpenBao will have to manually wait for this event, but PostgreSQL 19 will introduce a `WAIT FOR LSN` operation.\\n\\nThe benefits of this is that OpenBao will strictly follow PostgreSQL\u2019s lead: operators will promote or demote PostgreSQL nodes to primary, allowing writes to occur, and whichever OpenBao nodes are connected to it will then self-select to become active. No OpenBao specific failover is necessary.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-30.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nThe good news is that this approach will hopefully scale to any indexed replicated storage backend, and open up new opportunities in the future.\\n\\nThis is under active development and should be in OpenBao v2.7.0.\\n\\n(This photo showcases Target Field, where the Minnesota Twins play -- I hear the Linux Foundation has been organizing some visits to watch them play this week.)\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-31.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nBriefly before we wrap up, a few more things to mention:\\n\\n1. We\'re introducing stronger consistency semantics for clients through index headers, aligning with and extending Vault Enterprise\'s implementation here. This should hopefully help clients to see fewer stale reads.\\n2. We also have a roadmap towards write scalability through per-namespace storage backends.\\n\\nIn Vault Enterprise, this looks like the performance secondary cluster architecture, allowing a very limited form of write scalability: mounts (regardless of namespace) can be mou
1nted as cluster-local, essentially creating a forked/hybrid cluster. Plugin authors can also opt-in to write certain paths to cluster-local storage, such as the PKI plugin\u2019s leaf certificates. This has caused problems for plugins whose clients expect global knowledge: PKI\u2019s CRL functionality needed special cross-cluster synchronization support.\\n\\nOpenBao is thinking about this in a different way: by using namespaces as the isolating boundary, we know very few storage operations will cross the namespace boundary. This will form the basis for our envisioned multi-writer support: first we\u2019ll add lightweight storage separation (different tables at the BBolt and PostgreSQL levels) using the same storage backend, allowing things like namespace-level storage quotas. Then we\u2019ll introduce out-of-hierarchy namespaces, defined in the configuration file. These won\u2019t inherit policies and access from the root namespace, behaving more like a lightweight, fully-isolated core. Lastly, we\u2019ll move to separate storage backends altogether, adding in the ability for namespaces to designate themselves as active (versus a single global active node). This will allow write scalability across namespaces.\\n\\nUltimately, we hope this will lead to a different set of operator tradeoffs: the simplicity of a flat cluster (versus a treed hierarchy) should be easier for operators to understand and we\u2019ll have better write scalability across an entire cluster rather than on a more adhoc basis.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-32.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nLastly, if you\'re interested in getting involved with the project, check out our community calendar on Proton! You can contribute to a development direction item, join a working group, like our posts on social media, add your logo to the OpenBao Ecosystem page, or just start using OpenBao for your secrets management needs.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-ossna-26/Horizontal-Scalability-Slide-33.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nThank you very much!\\n\\nIf you have any questions later or just want OpenBao stickers, feel free to come and find me at the conference. I may be at the OpenSSF booth, but if not, they--or you--should be able to contact me on their Slack instance. John from ControlPlane and a newly announced OpenSSF Ambassador is also wandering around if I\'m busy!\\n\\nDoes anyone have questions now?"},{"id":"improved-horizontal-scalability","metadata":{"permalink":"/blog/improved-horizontal-scalability","source":"@site/content/blog/2026-03-25-improved-horizontal-scalabilty.md","title":"Improved Horizontal Scalability","description":"OpenBao v2.5.0 enables standby nodes to serve read requests, a first step towards better Horizontal Scalability.","date":"2026-03-25T00:00:00.000Z","tags":[{"inline":true,"label":"announcement","permalink":"/blog/tags/announcement"},{"inline":true,"label":"technical","permalink":"/blog/tags/technical"},{"inline":true,"label":"performance","permalink":"/blog/tags/performance"}],"readingTime":7.6,"hasTruncateMarker":true,"authors":[{"name":"Philipp Stehle","socials":{"github":"https://github.com/phil9909","linkedin":"https://www.linkedin.com/in/phil9909/"},"imageURL":"https://avatars.githubusercontent.com/phil9909","key":"phil9909","page":null}],"frontMatter":{"title":"Improved Horizontal Scalability","description":"OpenBao v2.5.0 enables standby nodes to serve read requests, a first step towards better Horizontal Scalability.","slug":"improved-horizontal-scalability","authors":"phil9909","tags":["announcement","technical","performance"],"image":"https://raw.githubusercontent.com/openbao/artwork/refs/heads/main/color/openbao-vertical-text-color.svg"},"unlisted":false,"prevItem":{"title":"OpenBao: Horizontally Scaling Secrets Management - OSSNA 2026","permalink":"/blog/cipherboy-ossna-26-talk"},"nextItem":{"title":"OpenBao\'s Roadmap and Community Direction for 2025-2026","permalink":"/blog/roadmap-2.0"}},"content":"## Summary\\n\\nIn this blog post, I will give you an overview of the new Horizontal Scalability\\nfeature of OpenBao, its (current) limitations and planned future developments.\\nIn the second part, I will show some benchmarks to see in which cases the new\\nfeature helps (spoiler: it works best in read-heavy workloads, but doesn\'t\\nimprove write-heavy workloads).\\n\\n\x3c!-- truncate --\x3e\\n\\n## Recap on Scalability Terminology\\n\\nLet\'s quickly recap what \\"horizontal\\" means in the context of scalability: To\\nscale a service up (i.e., allow it to handle more load
1) there are two options:\\nGive each instance more resources (CPU, memory, network speed, disk capacity,\\n...) or increase the number of instances. Increasing instance size is referred\\nto as \\"vertical\\" and increasing the number of instances is referred to as\\n\\"horizontal\\" scaling.\\n\\nWhether this is successful, depends on the problem at hand and the\\nimplementation. There are some problems that scale very well - both horizontally\\nand vertically - like serving static files. Given that the server is implemented\\nreasonably well, either doubling the resources per instance or doubling the\\nnumber of instances should both double the number of static files you can serve.\\nOnce you start to introduce mutability scalability starts to suffer, especially\\nif you want to provide strong consistency guarantees.\\n\\n## Recently released Horizontal Scalability Features\\n\\nWith OpenBao v2.5.0, we introduced what we call \\"read scalability\\". To ensure\\nHigh Availability, OpenBao has supported \\"standby nodes\\" since we forked from\\nVault. One of these nodes would automatically take over active duty, if the\\ncurrent leader nodes goes down (planned or unplanned). We extended this feature\\nto allow the \\"standby nodes\\" to become \\"read-only nodes\\", meaning they can now\\nserve read requests on their own, while write requests are still forwarded to\\nthe leader.\\n\\nThis has some limits:\\n\\n- The obvious being: If you have mostly write requests with only a few\\n read-only requests, then read scalability won\'t help.\\n\\n :::info\\n Keep in mind that a read request on the API level (e.g., HTTP GET) might still\\n require a write to the storage, e.g. [reading a dynamic secret from the\\n database plugin][dynamic-secrets] will require a write to storage, because\\n after its TTL has expired, it needs to be deleted and for this OpenBao has to\\n do \\"bookkeeping\\".\\n :::\\n\\n- Currently, only the Raft storage backend is supported. Support for PostgreSQL\\n is in the works.\\n\\nThere are also some caveats:\\n\\n- It might require changes to your load-balancer setup: If no traffic is routed\\n to the \\"read-only nodes\\", then they won\'t remove any load from the primary.\\n\\n- Data read from a standby node might be stale, if it has recently been updated\\n on the primary. If this is unacceptable to you in general, you can set\\n [`disable_standby_reads = true` in your configuration][disable_standby_reads]\\n to disable reads from standby. Or, if this is acceptable most of the time, you\\n can ensure to read from the primary in cases where you need the latest data.\\n\\n## Horizontal Scalability Outlook\\n\\nConsistent writing in a distributed fashion is an inherently hard problem. If we\\nwere set out to solve this in a general purpose way, we\'d be doomed to fail. We\\nneed to look out for properties of our specific case, that we can exploit:\\nCurrently, there is one leader node per cluster, which will handle all write\\nrequest. We are planning to change this and have leader nodes per namespace,\\nwhich will handle all write requests for their namespace. As write requests\\nbetween sibling namespaces are independent, there is no risk of violating data\\nintegrity (a property we can exploit :tada:).\\n\\nThis again has an obvious limitation: if you do not use namespaces or if most of\\nyour traffic is within a single namespace (e.g. you have a test and prod\\nnamespace and prod accounts for 99% of the load) this won\'t help. But let\'s take\\none step at a time and maybe it is even good enough, because a use cases is\\neither small enough to avoid scalability problems or big enough to require\\nnamespaces anyway.\\n\\nNow it is time to look at some benchmarks.\\n\\n## Benchmarks\\n\\n### Setup\\n\\nI have set up two 3-node OpenBao clusters on Azure, one running OpenBao 2.4.4\\nand one running OpenBao 2.5.1. Each cluster has a dedicated load balancer, but\\nthe load balancer for 2.4.4 is configured to direct traffic only to the primary\\nnode and the load balancer for the 2.5.1 cluster will distribute the traffic\\namong all nodes.\\n\\nI ran two benchmarks, one for the KV engine and one for the PKI engine. I ran\\nboth of them for 5 minutes per cluster using the [`benchmark-openbao`][] tool.\\n\\n### KV Engine Benchmark\\n\\
1nThe benchmark aims for 500 requests per second, with 90% reads and 10% writes.\\n\\n<details>\\n <summary>Full `benchmark-openbao` Config</summary>\\n\\n```hcl title=\\"benchmark_kv.hcl\\"\\nduration = \\"5m\\"\\ncleanup = true\\nworkers = 2000\\nrps = 500\\n\\ndisable_keep_alive = true\\n\\ntest \\"kvv1_write\\" \\"writes\\" {\\n weight = 10\\n config {\\n numkvs = 10\\n kvsize = 100\\n }\\n}\\n\\ntest \\"kvv1_read\\" \\"reads\\" {\\n weight = 90\\n config {\\n numkvs = 10\\n kvsize = 100\\n }\\n}\\n```\\n\\n</details>\\n\\nIf we take a look at the per-node CPU usage, we can clearly see the effects. The\\nfirst plot shows the CPU usage of the 2.4.4 cluster over a 15 minute timespan\\n(average per minute) with the 5 minute benchmark roughly centered. Before and\\nafter the benchmark, we can see the active node hovering around 4% CPU usage,\\nwhile the standbys use around 2%. During the benchmark it raises to around 60%\\nfor the primary and 8% for the standbys.\\n\\n\\n\\nThe next plot shows the same data for the 2.5.1 cluster. In the first plot\\nwe could clearly see which line is the primary, but here all lines are very\\nsimilar. Before and after the benchmark the CPU usage hovers around 4% jumping\\nup to 30 to 35% for all nodes during the benchmark.\\n\\n\\n\\nThis results in better latencies:\\n\\n| operation | version | mean | 95th% | 99th% | count |\\n|-----------|--------:|------------:|------------:|------------:|---------:|\\n| reads | 2.5.1 | 5.75 ms | 19.55 ms | 36.94 ms | 1349402 |\\n| | 2.4.4 | 7.92 ms | 28.69 ms | 51.64 ms | 1350523 |\\n| writes | 2.5.1 | 58.08 ms | 105.90 ms | 239.21 ms | 150598 |\\n| | 2.4.4 | 87.21 ms | 201.23 ms | 355.96 ms | 149477 |\\n\\n\\n:::info[Averaged Results]\\nWhile the Graphs above show a single benchmark run, the tables are the combined\\nnumbers of several benchmark runs.\\n:::\\n\\n### PKI Engine Benchmark\\n\\nThe benchmarks aims for only 5 requests per second, generating RSA 2048\\ncertificates with [`no_store = true`][no_store], which makes this a read-only\\noperation. Generating a (RSA) private key is quite heavy on the CPU, therefore\\nthe low number of requests.\\n\\n<details>\\n <summary>Full `benchmark-openbao` Config</summary>\\n\\n```hcl title=\\"benchmark_pki_rsa2048_no_store.hcl\\"\\nduration = \\"5m\\"\\ncleanup = true\\nworkers = 15\\nrps = 5\\n\\ndisable_keep_alive = true\\n\\ntest \\"pki_issue\\" \\"pki_issue\\" {\\n weight = 100\\n config {\\n setup_delay=\\"2s\\"\\n root_ca {\\n common_name = \\"benchmark.test Root Authority\\"\\n key_type = \\"rsa\\"\\n key_bits = \\"2048\\"\\n }\\n intermediate_csr {\\n common_name = \\"benchmark.test Intermediate Authority\\"\\n key_type = \\"rsa\\"\\n key_bits = \\"2048\\"\\n }\\n role {\\n ttl = \\"10s\\"\\n no_store = true\\n generate_lease = false\\n key_type = \\"rsa\\"\\n key_bits = \\"2048\\"\\n }\\n }\\n}\\n```\\n\\n</details>\\n\\n:::tip[Performance Tip]\\nIf you are using the PKI engine and issue a fair amount of certificates, you\\nshould consider [using Certificate Signing Requests (CSRs)][use-csr] instead of\\ngenerating the private key on the OpenBao cluster. Also, using ECDSA or Ed25519\\ninstead of RSA where possible will improve the performance, see \\"[Key types\\nmatter][]\\"\\n:::\\n\\n\\n\\nHere again we have two graphs, first from the 2.4.4 cluster followed by the\\n2.5.1 cluster. During idle the results are the same as before.\\n\\nOn 2.4.4 cluster the primary spikes to 100% CPU usage, while the standbys don\'t\\nsee any change (because in contrast to the KV benchmark there are no writes\\nhappening, so they have no raft updates to apply).\\n\\n\\n\\nOn the 2.5.1 cluster the load is spread pretty well at roughly 40%.\\n\\n\\n\\nThis time we also see better latencies, but additionally the 2.4.4 cluster\\nfailed to even fulfill the 5 requests per second target and some requests (0.73%)\\neven failed.\\n\\n| version | mean | 95th% | 99th% | count | rate | success |\\n|--------:|------------:|------------:|------------:|---------:|-------:|---------:|\\n| 2.5.1 | 566.77 ms | 1976.84 ms | 3575.30 ms | 15000 | 5.00 | 100.00 % |\\n| 2.4.4 | 11668.62 ms | 27152.59 ms | 38203.77 ms | 3990 | 1.33 | 99.27 % |\\n\\n### Missing Benchmarks\\n\\nI decided against showing a write heavy benchmark, like PKI with `no_store =\\nfalse` or KV with 100% write. Not because I want to hide the fact that our read\\nscalability feature does not help here, but because it would be boring to look\\nat. The results for both versions would be similar, the only change you could\\nsee is that for 2.5.1 the standby nodes use a little more CPU while the cluster\\nis idle (as we have seen before).\\n\\n[disable_standby_reads]: /docs/configuration\\n[dynamic-secrets]: /docs/secrets/databases/#usage\\n[Key types matter]: /docs/secrets/pki/considerations/#key-types-matter\\n[no_store]: /docs/api/secret/pki/#create-update-role\\n[use-csr]: /docs/api/secret/pki/#sign-certificate\\n[`benchmark-openbao`]: https://github.com/openbao/benchmark-openbao"},{"id":"roadmap-2.0","metadata":{"permalink":"/blog/roadmap-2.0","source":"@site/content/blog/2025-10-20-roadmap-2.0.md","title":"OpenBao\'s Roadmap and Community Direction for 2025-2026","description":"An explanation of OpenBao\'s proposed roadmap and direction for the community for 2025-2026.","date":"2025-10-20T00:00:00.000Z","tags":[{"inline":true,"label":"direction","permalink":"/blog/tags/direction"},{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"collaboration","permalink":"/blog/tags/collaboration"}],"readingTime":2.93,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao\'s Roadmap and Community Direction for 2025-2026","description":"An explanation of OpenBao\'s proposed roadmap and direction for the community for 2025-2026.","slug":"roadmap-2.0","authors":"cipherboy","tags":["direction","community","collaboration"],"image":"https://raw.githubusercontent.com/openbao/artwork/refs/heads/main/color/openbao-vertical-text-color.svg"},"unlisted":false,"prevItem":{"title":"Improved Horizontal Scalability","permalink":"/blog/improved-horizontal-scalability"},"nextItem":{"title":"The Perfectly Unperfect Mentorship","permalink":"/blog/mentorship-program"}},"content":"As the summer of 2025 closed, OpenBao\'s Dev WG and TSC put together and\\napproved [a new technical direction and roadmap for 2025-2026](https://github.com/openbao/openbao/issues/1974).\\nBut before we get into the details, I think is important to look back at\\nand celebrate what all we\'ve accomplished this year:\\n\\n1. Many technical initiatives have landed, from namespaces to transactional\\n storage, to CEL support, and many smaller things in between.\\n2. Many continuing working groups and large technical initiates have been\\n started, from the horizontal scalability WG, focused on read scalability;\\n the UI WG, focused on a rewrite of our EmberJS Web UI into React; to the\\n PKCS#11/KMS WG, focused on including external keys into OpenBao. Thank you\\n to everyone who participates in these!\\n3. [Many, many contributions from many, many contributors](https://insights.linuxfoundation.org/project/openbao-2/contributors?timeRange=past365days&start=2024-10-20&end=2025-10-20&auth=success)!\\n We welcomed:\\n\\n - 741 commits to [`main`](https://github.com/openbao/openbao/commits/main/?since=2024-09-30&until=2025-10-20),\\n - 287 contributors in the past year,\\n - 10 new committers, and\\n - 4 new moderators!\\n\\n And like I say nearly every meeting, a special thanks to all net-new\\n contributors! A fresh set of eyes brings wonders to a
1storied project,\\n and often revisiting earlier design choices let us improve the experience.\\n\\nAnd yes, not everything on [the 2024-2025 roadmap](https://github.com/openbao/openbao/issues/569)\\nwas completed. Don\'t worry, you can still contribute items from it if you\\nwant! But for a community just starting out, with its first formal direction\\nproposal, I think the response we got exceeded my wildest expectations.\\n\\n\x3c!-- truncate --\x3e\\n\\n---\\n\\nMuch like last year, [this roadmap](https://github.com/openbao/openbao/issues/1974)\\nopens with three major categories:\\n\\n> 1. \\"**<i>O</i>perator Experience**\\": to enable easier or safer operation of OpenBao, through changes like profiles, break-glass and backup/restore procedures, and improved monitoring capabilities;\\n> 2. \\"**<i>S</i>calability**\\": to improve optimization and utilization of OpenBao in large, complex environments; and\\n> 3. \\"**<i>S</i>ustainability**\\": to ensure the long-term viability of the code base, react to changing secrets management directives, and stabilize our ability to maintain the project indefinitely.\\n\\nTogether, these spell _OSS_, reaffirming our commitment to an [open-source\\nproject](https://github.com/openbao/openbao/blob/main/LICENSE) lead under\\n[open governance principals](https://github.com/openbao/openbao/blob/main/CHARTER.md).\\n\\nLike last time, our roadmap features several items I\'d especially like to\\nhighlight:\\n\\n1. Expanding **CEL Support** for non-ACL policies, in the profile system,\\n and other plugins. This allows greater operator control over authentication\\n and authorization. _Operator Experience_.\\n2. **Lazy loading of mounts, namespaces**, removing them from memory when no\\n requests have accessed the path in a while. This would allow OpenBao to be\\n substantially over-committed if workload allows. _Scalability_.\\n3. **KMIP Server for Transit** and **PKCS#11 client for Transit**, to allow\\n consumption and safe usage of Transit-stored keys from other servers via\\n KMIP and PKCS#11 protocols. _Sustainability_.\\n4. **Usage guides** and tutorials for various components. _Sustainability_.\\n5. **Versioned documentation** so that pre-release features do not show in\\n the documentation by default and documentation for particular releases\\n are maintained accordingly. _Sustainability_.\\n\\n:::info\\nInterested in some of these features? We need your help!\\n\\nReact (:+1:) to issues on GitHub to show your support, help contribute use\\ncases or design documents, or submit code implementing these features! If you\\nneed help getting started, [just reach out](https://github.com/openbao/#contact)!\\n:::"},{"id":"mentorship-program","metadata":{"permalink":"/blog/mentorship-program","source":"@site/content/blog/2025-09-23-mentorship-program.md","title":"The Perfectly Unperfect Mentorship","description":"No blueprint, no problem. How a 12-week experiment in guided chaos delivered a performance breakthrough.","date":"2025-09-23T00:00:00.000Z","tags":[{"inline":true,"label":"mentorship","permalink":"/blog/tags/mentorship"},{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"opensource","permalink":"/blog/tags/opensource"},{"inline":true,"label":"collaboration","permalink":"/blog/tags/collaboration"}],"readingTime":4.76,"hasTruncateMarker":true,"authors":[{"name":"Andrii Fedorchuk","socials":{"github":"https://github.com/driif","linkedin":"https://www.linkedin.com/in/andrii-fedorchuk-b966911b9/"},"imageURL":"https://andrii.fedorchuk.me/public/images/IMG_2360_2.JPG","key":"AndriiFedorchuk","page":null}],"frontMatter":{"title":"The Perfectly Unperfect Mentorship","description":"No blueprint, no problem. How a 12-week experiment in guided chaos delivered a performance breakthrough.","slug":"mentorship-program","authors":"AndriiFedorchuk","tags":["mentorship","community","opensource","collaboration"]},"unlisted":false,"prevItem":{"title":"OpenBao\'s Roadmap and Community Direction for 2025-2026","permalink":"/blog/roadmap-2.0"},"nextItem":{"title":"It\'s a wrap! OpenBao at Open Source Summit Europe 2025","permalink":"/blog/wrap-openbao-oss-europe-2025"}},"content":"Imagine starting a mentorship program with a big goal and... not a perfect plan. Sound familiar? That was us, three months ago. We had a brilliant mentee, [**Fatima Patel**](https://github.com/fatima2003), a crucial feature for OpenBao\u2019s roadmap, and a healthy dose of \\"let\'s figure this out as we go.\\"\\n\\nSpoiler alert: it worked. Spectacularly. But not because we had all the answers on day one. It worked because we treated the mentorship itself like an open-source project: we iterated, adapted, and optimized for success in real-time.\\n\\nThis is the story of how we structured\u2014and restructured\u2014a 12-week program that ended up giving OpenBao a scalability boost and fantastic contributions.\\n\\n\x3c!-- truncate --\x3e\\n\\n#### **The Setup: An Experiment with High Stakes**\\n\\
1nThe goal was ambitious: transform OpenBao\u2019s **passive standby nodes** into **active cluster participants** that can handle read requests, a key step towards horizontal scalability. [**Adfinis**](https://www.adfinis.com/) provided the crucial fuel by funding the program, and the initiative was kicked off by [**Alexander Scheel**](https://github.com/cipherboy), who created [the project on the LFX Mentorship Platform](https://mentorship.lfx.linuxfoundation.org/project/d419da30-b718-435d-8673-6c1260307339).\\n\\nMy role was to be the primary mentor. This was a shared investment: Adfinis invested funds and my time, while Fatima invested her talent and immense effort.\\n\\nWe started with a hypothesis: intensive, daily collaboration would be the fastest way to onboard her into the complex codebase.\\n\\n#### **The Rhythm of Mentorship: Finding Our Flow**\\n\\nFor the first few weeks, we met **every single day for an hour**. This intensive pace was essential for building context and momentum. But we quickly learned that the magic wasn\'t just in the meetings\u2014it was in the deep, uninterrupted work happening in between.\\n\\nSo, we adapted. Around the halfway mark, we shifted our rhythm to **three meetings per week**. This wasn\'t a step back; it was a strategic pivot. The focus moved away from daily \\"what do we do next?\\" check-ins to structured sessions where we could define clear tasks for the upcoming week. This gave Fatima the autonomy for deep, focused work and essential self-teaching, while ensuring she always had support to overcome obstacles.\\n\\nAnd the support team grew! In the second part of the program, Fatima had the fantastic opportunity to work closely with [**Philipp Stehle**](https://github.com/phil9909) from Adfinis, who was tackling cache invalidation challenges between nodes. This turned the mentorship into a true team collaboration. Instead of one mentor, she effectively had two, which was an incredible advantage and made the experience much more dynamic.\\n\\n#### **The Mentee\u2019s Lens: Lessons Beyond the Code**\\n\\n>From my side of the screen, this mentorship was more than a 12-week coding sprint \u2014 it taught me the importance of confidence, perseverance and how collaboration and adapting strategies as new problems arise are essential parts of working effectively in a team.\\n>\\n>When we initially discussed horizontal scalability as the topic for the mentorship, I remember feeling underprepared, having never worked in that space before. My mentor, [Andrii](https://github.com/driif)\u2019s uplifting encouragement and guidance helped me dive in, understand the problem space, and start experimenting with solutions. Once [Philipp](https://github.com/phil9909) joined the project, the pace picked up and the discussions became even more engaging.\\n>\\n>The community also held bi-monthly meetings led by [Alex](https://github.com/cipherboy) to review progress on high availability and discuss next steps. These sessions ensured the work stayed aligned with the community\u2019s goals and that our progress moved in the right direction.\\n>\\n>Looking back, the experience shaped not just how I write code, but how I approach challenges \u2014 with curiosity, collaboration, and confidence!\\n\\n#### **The 12-Week Sprint: A Choice We\'d Make Again**\\n\\nThe LFX platform offers 12-week full-time or 24-week part-time programs. We\u2019re incredibly glad Fatima chose the **12-week option**. It forced a healthy intensity\u2014a focused sprint that kept everyone laser-focused on the goal: delivering a tangible, impactful feature for the community.\\n\\nAnd what a feature it was. Under this adapted structure, Fatima\u2019s contributions were profound:\\n* She enabled **standby nodes to handle read requests**, a fundamental shift from idle replicas to active participants.\\n* She implemented the **post-unsealing logic**, ensuring standbys are fully initialized and ready to work.\\n\\nThe result? A foundational improvement that makes OpenBao clusters more efficient and performant. Standby nodes are no longer resource-consuming fallback insurance; they are now part of the active workforce.\\n\\n#### **The Real Win: A Model for Community-Led Growth**\\n\\nThis program was a win on every level.\\n* **For OpenBao:** We gained a critical feature from our roadmap and a valuable contributor.\\n* **For Fatima:*
1* She tackled a complex project with direct, high-impact outcomes and the support of a collaborative team.\\n* **For [Adfinis](https://www.adfinis.com/):** The investment in funding and our time directly contributed to the health of an open-source project we believe in.\\n\\nThe real success wasn\'t just the code. It was proving that with the right combination of **funding, flexibility, and a team spirit**, you can structure a mentorship to achieve incredible things. It\u2019s about creating a focused environment where a talented developer, like [**Fatima Patel**](https://github.com/fatima2003), can deeply integrate with a maintainer\'s workflow to accelerate complex, high-impact projects that benefit the entire community.\\n\\nThis is how we build a sustainable open-source future: not by waiting for perfect plans, but by creating opportunities, adapting as we go, and investing in people.\\n\\n**Want to learn more about the technical outcomes?** Check out the pull requests and join the conversation on our [OpenBao GitHub repository](https://github.com/openbao/openbao).\\n\\n**Inspired to get involved?** Explore the [LFX Mentorship Platform](https://mentorship.lfx.linuxfoundation.org/project/d419da30-b718-435d-8673-6c1260307339) and see how you can contribute."},{"id":"wrap-openbao-oss-europe-2025","metadata":{"permalink":"/blog/wrap-openbao-oss-europe-2025","source":"@site/content/blog/2025-08-28-openbao-oss-europe-2025-wrap.md","title":"It\'s a wrap! OpenBao at Open Source Summit Europe 2025","description":"OpenBao joined the Open Source Summit EU 2025 in Amsterdam and gave roadmap previews, Q&A, and hands-on conversations about open-source secrets management.","date":"2025-08-28T00:00:00.000Z","tags":[{"inline":true,"label":"announcement","permalink":"/blog/tags/announcement"},{"inline":true,"label":"conferences","permalink":"/blog/tags/conferences"},{"inline":true,"label":"community","permalink":"/blog/tags/community"}],"readingTime":1.38,"hasTruncateMarker":true,"authors":[{"name":"Christoph Voigt","url":"https://www.christophvoigt.com","socials":{"github":"https://github.com/voigt","linkedin":"https://www.linkedin.com/in/chris-cloud-native/","mastodon":"https://hachyderm.io/@cv"},"imageURL":"https://christophvoigt.com/img/author.jpg","key":"ChristophVoigt","page":null}],"frontMatter":{"title":"It\'s a wrap! OpenBao at Open Source Summit Europe 2025","description":"OpenBao joined the Open Source Summit EU 2025 in Amsterdam and gave roadmap previews, Q&A, and hands-on conversations about open-source secrets management.","slug":"wrap-openbao-oss-europe-2025","authors":"ChristophVoigt","tags":["announcement","conferences","community"],"image":"/img/openbao-osseu-2025.jpg"},"unlisted":false,"prevItem":{"title":"The Perfectly Unperfect Mentorship","permalink":"/blog/mentorship-program"},"nextItem":{"title":"Meet OpenBao at Open Source Summit Europe 2025","permalink":"/blog/meet-openbao-oss-europe-2025"}},"content":"The OpenBao community had a great time at **[Open Source Summit Europe 2025](https://events.linuxfoundation.org/open-source-summit-europe/)**! The event once again showed how strong the demand for secure and reliable secret management in enterprise environments has become.\\n\\nOne theme was clear: Companies and individuals demand tools to manage secrets across their systems, and solutions like OpenBao are foundational for security and compliance.\\n\\n\\n\\n\x3c!-- truncate --\x3e\\n\\nTogether with the Team from RISC-V and DeepComputing we were able to successfully test our riscv64 binaries on a DeepComputing DC-ROMA RISC-V laptop. With our added RISC-V support in [PR #168](https://github.com/openbao/openbao/pull/168) this was super easy and just worked out of the box.\\n\\nThroughout the conference, we shared how OpenBao is able to help organizations to run production workloads securely. We showcased existing features such as strong encryption, fine-grained access controls and namespace isolation. We also gave a glimpse into what\u2019s next: declarative initialization, improvements around namespaces and extended key management capabilities.\\n\\nFurthermore, the conference was also a wonderful opportunity for OpenBao maintainers to meet in person, exchange ideas, and align on next steps. A big thank you goes to [**Adfinis**](https://adfinis.com/), [**Paymenttools**](https://www.paymenttools.com/) and [**Reply**](https://www.reply.com/), who supported the project by sending maintainers to represent OpenBao on-site.\\n\\nAnd finally, a heartfelt thanks to everyone who stopped by, joined discu
1ssions, or offered feedback. Your energy and curiosity keep the project moving forward. To everyone who was not able to join the conference, feel free to learn more at [**openbao.org**](/community/contributing/) or join the conversation on [**GitHub**](https://github.com/openbao)."},{"id":"meet-openbao-oss-europe-2025","metadata":{"permalink":"/blog/meet-openbao-oss-europe-2025","source":"@site/content/blog/2025-08-19-meet-openbao-oss-europe-2025.md","title":"Meet OpenBao at Open Source Summit Europe 2025","description":"Join us in Amsterdam 25\u201327 August for roadmap previews, deep-dive Q&A, and hands-on conversations about open-source secrets management.","date":"2025-08-19T00:00:00.000Z","tags":[{"inline":true,"label":"announcement","permalink":"/blog/tags/announcement"},{"inline":true,"label":"conferences","permalink":"/blog/tags/conferences"},{"inline":true,"label":"community","permalink":"/blog/tags/community"}],"readingTime":3.06,"hasTruncateMarker":true,"authors":[{"name":"Andrii Fedorchuk","socials":{"github":"https://github.com/driif","linkedin":"https://www.linkedin.com/in/andrii-fedorchuk-b966911b9/"},"imageURL":"https://andrii.fedorchuk.me/public/images/IMG_2360_2.JPG","key":"AndriiFedorchuk","page":null}],"frontMatter":{"title":"Meet OpenBao at Open Source Summit Europe 2025","description":"Join us in Amsterdam 25\u201327 August for roadmap previews, deep-dive Q&A, and hands-on conversations about open-source secrets management.","slug":"meet-openbao-oss-europe-2025","authors":"AndriiFedorchuk","tags":["announcement","conferences","community"],"image":"/img/meet_bao.png"},"unlisted":false,"prevItem":{"title":"It\'s a wrap! OpenBao at Open Source Summit Europe 2025","permalink":"/blog/wrap-openbao-oss-europe-2025"},"nextItem":{"title":"OpenBao Joins the OpenSSF to Advance Secure Secrets Management in Open Source","permalink":"/blog/openbao-joins-the-openssf"}},"content":"\\n\\nOpen source builders, security engineers, and platform teams are converging on Amsterdam and OpenBao will be in the middle of it, thanks to the generosity of the Linux Foundation.\\n\\nWe\u2019re excited to announce our first official booth at **[Open Source Summit Europe 2025](https://events.linuxfoundation.org/open-source-summit-europe/)**. If you care about secure automation, multi\u2011tenant architectures, or meeting the stewards of your critical infrastructure tooling, come talk with us!\\n\\nOfficial event site: [Open Source Summit Europe](https://events.linuxfoundation.org/open-source-summit-europe/)\\n\\n**Find Us** \\nEvent: Open Source Summit Europe 2025 \\nDates: 25\u201327 August 2025 \\nLocation: RAI Amsterdam, Netherlands \\nBooth: `G/S7` \\nHashtag: `#OSSummit` `#OpenBao` \\n\\nThis isn\u2019t just a swag stop (expect some stickers); it\u2019s a place to trade real-world stories, get practical guidance, and influence the [OpenBao roadmap](https://github.com/openbao/openbao/issues/569), now ready for its second iteration!\\n\\n\x3c!-- truncate --\x3e\\n\\n<figure>\\n\\t<img src=\\"/img/ossummit_bao_booth.png\\" alt=\\"OpenBao booth preview at OSS Europe\\" />\\n\\t<figcaption><em>Can you spot Bao in the booth mock? Try to find Bao on the picture!</em></figcaption>\\n</figure>\\n\\n## What You\u2019ll Get at the Booth\\n\\n**Guided Walkthroughs** \u2013 We\u2019ll walk you through the latest capabilities: Namespaces, advanced policy handling, paginated lists, and more... Ask deep architectural questions (scaling, HSM integrations, and migration strategies) and get answers from the people writing the code.\\n\\n**Deployment & Design Q&A** \u2013 Are you architecting resilient deployments, tightening policy boundaries, or integrating with existing PKI or signing workflows? Bring real problems, leave with practical next steps.\\n\\n**Roadmap Preview** \u2013 Near\u2011term energy: safer ops (policy and audit hygiene), resilience (parallel and namespace unseal), practical scalability (standby node read request handling). Bigger ecosystem/registry ideas come later. Tell us what you need most!\\n\\
1n**Community Meetups** \u2013 Connect with maintainers, contributors, downstream integrators, and fellow operators. Hallway conversations around pain points often become features.\\n\\n**Contribution Guidance** \u2013 Want to help? We\u2019ll highlight good first issues, active design discussions, and how to start, whether you\'re an experienced developer new to Open Source, someone looking to get into technical writing, or anything in between!\\n\\n## Why It Matters\\n\\nOpenBao represents a community\u2011first, transparently governed evolution in secrets management. No lock\u2011in. No unclear licensing pivots. Just open, auditable, extensible security primitives stewarded in the open. Our presence at OSS Europe marks a milestone in maturity\u2014and a recommitment to collaborative innovation.\\n\\n## Who Should Stop By?\\n\\n- OSPS leadership looking to understand viable alternatives to their company\'s vendor lock-in problems\\n- Platform & DevSecOps teams standardizing secret workflows\\n- Security engineers evaluating trust, provenance, and lifecycle controls\\n- Architects designing regulated or multi\u2011tenant environments\\n- Contributors (or future ones) curious where to jump in\\n- Anyone comparing OpenBao with legacy or closed models\\n\\n## Key Themes We\u2019ll Be Talking About\\n\\n- Secure multi\u2011tenancy with Namespaces\\n- Operational trust: auditing, rotation, lifecycle management\\n- Plugin & ecosystem growth\\n- Secrets management at scale\\n- Community governance & sustainability\\n\\n## Engage Before / During / After\\n\\n- Plan Your Visit: Add our booth to your event schedule (check the published schedule once live).\\n- Register: Early reg & travel info via the event site\u2019s [registration page](https://events.linuxfoundation.org/open-source-summit-europe/register/).\\n- Follow Along: [openbao.org](https://openbao.org) & our LinkedIn page ([OpenBao on LinkedIn](https://www.linkedin.com/company/openbao)) for micro\u2011updates and drop\u2011in session times.\\n- Ask Early: Have a thorny problem? Post it in advance in community channels so we can prep a live walkthrough.\\n- Remote? We\u2019ll share recaps, photos, and key takeaways using `#OSSummit` and `#OpenBao`.\\n\\n## Call to Action\\n\\nShow up. Challenge us. Tell us what you need from the next generation of open\u2011source secrets management, and help build and shape it. OpenBao moves fastest when the community is loud.\\n\\nSee you in Amsterdam! \\n\u2014 The OpenBao Team"},{"id":"openbao-joins-the-openssf","metadata":{"permalink":"/blog/openbao-joins-the-openssf","source":"@site/content/blog/2025-06-17-openbao-to-openssf.mdx","title":"OpenBao Joins the OpenSSF to Advance Secure Secrets Management in Open Source","description":"OpenBao has moved into the OpenSSF, building stronger partnerships for the future.","date":"2025-06-17T00:00:00.000Z","tags":[{"inline":true,"label":"announcement","permalink":"/blog/tags/announcement"},{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"collaboration","permalink":"/blog/tags/collaboration"}],"readingTime":2.74,"hasTruncateMarker":true,"authors":[{"name":"OpenSSF","url":"https://openssf.org","socials":{"github":"https://github.com/ossf","linkedin":"https://www.linkedin.com/company/openssf/","mastodon":"https://social.lfx.dev/@openssf"},"imageURL":"https://raw.githubusercontent.com/ossf/artwork/refs/heads/main/openssf/stacked/color/openssf-stacked-color.png","key":"OpenSSF","page":null}],"frontMatter":{"title":"OpenBao Joins the OpenSSF to Advance Secure Secrets Management in Open Source","description":"OpenBao has moved into the OpenSSF, building stronger partnerships for the future.","slug":"openbao-joins-the-openssf","authors":"OpenSSF","tags":["announcement","community","collaboration"],"image":"https://openssf.org/wp-content/uploads/2025/06/OpenSSF-Blog-Graphics-53-1.png"},"unlisted":false,"prevItem":{"title":"Meet OpenBao at Open Source Summit Europe 2025","permalink":"/blog/meet-openbao-oss-europe-2025"},"nextItem":{"title":"Announcing OpenBao Namespaces","permalink":"/blog/namespaces-announcement"}},"content":"import Head from \'@docusaurus/Head\';\\n\\n<Head>\\n <link rel=\\"canonical\\" href=\\"https://openssf.org/blog/2025/06/17/openbao-joins-the-openssf-to-advance-secure-secrets-management-in-open-source/\\" />\\n</Head>\\n\\n\\n\\nWe\u2019re excited to welcome [OpenBao](https://openssf.org/projects/openbao/) to the [Open Source Security Foundation (OpenSSF)](https://openssf.org) as a newly accepted [sandbox project](https://openssf.org/projects/openbao/)!\\n\\nOpenBao is an open source identity-based secrets and encryption management system that helps organizations securely store, manage, and audit access to sensitive data like API keys, passwords, and certificates. Originally developed under LF Edge and forked from HashiCorp Vault, OpenBao has now found its new home in the OpenSSF, where it aligns more directly with the needs of security professionals and open source maintainers.\\n\\n\u201CJoining OpenSSF has been a dream come true,\u201D said **Alex Scheel**, Chair of the OpenBao Technical Steering Committee. \u201CThis wouldn\u2019t be possible without the support of OpenSSF\u2019s Technical Advisory Council\u2014many thanks for their help and consideration!\u201D\\n\\n\x3c!-- truncate --\x3e\\n\\n## Why OpenBao?\\n\\nModern systems rely on a growing number of secrets to operate securely\u2014from database credentials to cloud service API tokens. Managing and auditing access to these secrets is complex, and building custom solutions can introduce more risk than reward. OpenBao solves this problem by providing robust encryption services that are tightly gated by authentication and authorization controls. It integrates with the tools and ecosystems open source developers and security teams already use, including Sigstore and SLSA.\\n\\nThrough its CLI, UI, and HTTP API, OpenBao makes it easier to:\\n\\n - Securely manage and distribute secrets across teams and environments\\n - Apply fine-grained access controls\\n - Rotate keys and credentials automatically\\n - Maintain detailed audit trails for compliance and incident response\\n\\n## Moving to the OpenSSF\\n\\nThe move from LF Edge to OpenSSF reflects a strategic decision by OpenBao\u2019s Technical Steering Committee to better align with its contributor base and project mission. While the project is deeply grateful for the support from LF Edge during its early development, the OpenSSF offers a broader and more targeted platform to grow its community and expand adoption.\\n\\n\u201CWe\u2019re looking forward to collaborating with various working groups and SIGs within OpenSSF\u2014especially to help strengthen secrets management best practices in open source policy and guidance,\u201D said Scheel. \u201CWe also remain committed to maintaining partnerships with LF Edge and other Linux Foundation projects as our ecosystems evolve.\u201D\\n\\n## What\u2019s Next\\n\\nNow in the sandbox stage of OpenSSF\u2019s project lifecycle, OpenBao is focused on increasing transparency, improving governance, and deepening integration with other OpenSSF initiatives. Its ongoing work will support supply chain security, secrets hygiene, and broader security-by-design efforts across open source projects.\\n\\nWe\u2019re thrilled to support the OpenBao community and look forward to seeing its impact grow across the open source security landscape.\\n\\n\u{1F510} Get Involved: [Visit the OpenBao GitHub repository](https://github.com/openbao/openbao) and join the conversation on the [OpenSSF Slack](https://linuxfoundation.slack.com/archives/C02H1G4TH) and [Zulip](https://linuxfoundation.zulipchat.com/#narrow/channel/529890-openssf-openbao-discussion).\\n\\n---\\n\\nThis post was originally authored by the OpenSSF marketing team and posted on [the OpenSSF blog](https://openssf.org/blog/2025/06/17/openbao-joins-the-openssf-to-advance-secure-secrets-management-in-open-source/)."},{"id":"namespaces-announcement","metadata":{"permalink":"/blog/namespaces-announcement","source":"@site/content/blog/2025-05-30-namespaces-announcement.md","title":"Announcing OpenBao Namespaces","description":"Enabling Multi-Tenancy within OpenBao","date":"2025-05-30T00:00:00.000Z","tags":[{"inline":true,"label":"announcement","permalink":"/blog/tags/announcement"},{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"collaboration","permalink":"/blog/tags/collaboration"}],"readingTime":5.25,"hasTruncateMarker":true,"authors":[{"name":"Christoph Voigt","url":"https://www.christophvoigt.com","socials":{"github":"https://github.com/voigt","linkedin":"https://www.linkedin.com/in/chris-cloud-native/","mastodon":"https://hachyderm.io/@cv"},"imageURL":"https://christophvoigt.com/img/author.jpg","key":"ChristophVoigt","page":null}],"frontMatter":{"title":"Announcing OpenBao Namespaces","description":"Enabling Multi-Tenancy within OpenBao","slug":"namespaces-announcement","authors":"ChristophVoigt","tags":["announcement","community","collaboration"]},"unlisted":false,"prevItem":{"title":"OpenBao Joins the OpenSSF to Advance Secure Secrets Management in Open Source","permalink":"/blog/openbao-joins-the-openssf"},"nextItem":{"title":"OpenBao Adopted as the Secret Store for EdgeX Foundry","permalink":"/blog/edgex-selects-openbao"}},"content":"We are excited to introduce **Namespaces** to the OpenBao Secret Manager \u2013 a powerful feature designed to bring robust multi-tenancy and fine-grained isolation to your secrets management workflows.\\n\\n## What Are Namespaces?\\n\\nNamespaces in OpenBao are logical partitions within a single OpenBao instance, functioning as isolated environments where teams, organizations, or applications can operate independently.\\n\\nEach namespace acts like a mini-OpenBao, with its own policies, authentication methods, secret engines, tokens, and identity groups. This architecture enables organizations to implement a true _OpenBao-as-a-Service_ model, empowering internal
1customers to self-manage their environments securely and efficiently.\\n\\n\x3c!-- truncate --\x3e\\n\\n## Why Namespaces?\\n\\nStrong isolation between teams, business units, or tenants becomes critical as organizations scale, especially when handling sensitive data.\\n\\nNamespaces enable secure multi-tenancy. Each tenant (e.g., team, organisation, or application) operates within its namespace, isolated from others. Permissions are strictly scoped, preventing users from accessing or interfering with resources outside their assigned namespace.\\n\\nFurthermore, namespaces enable the delegation of administration and promote self-service. Namespace admins can manage their own policies, secret engines, auth modes, or even quotas, without impacting other tenants, reducing the burden on cluster-level operators.\\n\\nFinally, namespaces are one of a few planned stepping stones towards OpenBao\'s [horizontal scalability](/blog/vision-for-namespaces/) journey. OpenBao aims to allow support for large deployments with many infrequently accessed mounts, without overloading cluster nodes, while keeping a simpler cluster topology.\\n\\n## How to use Namespaces\\n\\nNamespaces will enable plenty of use cases and multi-tenancy scenarios. Let\'s consider a possible namespace setup for a SaaS Company. The platform team retains a top-level namespace for shared infrastructure. On the other hand, each tenant receives a fully isolated namespace to, e.g., model a staging system.\\n\\n<figure>\\n```mermaid \\ngraph LR\\n\\nroot[\\"/\\"]\\n\\nroot --\x3e platform[platform]\\nplatform --\x3e infra[infra]\\nplatform --\x3e monitoring[monitoring]\\nplatform --\x3e devtools[devtools]\\n\\nroot --\x3e tenants[tenants]\\n\\ntenants --\x3e tenantA[tenant-a]\\ntenantA --\x3e devA[dev]\\ntenantA --\x3e stagingA[staging]\\ntenantA --\x3e prodA[prod]\\n\\ntenants --\x3e tenantB[tenant-b]\\ntenantB --\x3e devB[dev]\\ntenantB --\x3e prodB[prod]\\n\\ntenants --\x3e tenantC[tenant-c]\\ntenantC --\x3e prodC[prod]\\n```\\n<figcaption>An example namespace structure to separate tenants and the platform team.</figcaption>\\n</figure>\\n\\nTo use this new feature, no extra setup or configuration is required. The OpenBao CLI now features a special `namespace` sub-command, which can be used to administrate Namespaces.\\n\\nTo recreate the structure of the given example, we would do the following workflow:\\n\\n1. **Create Namespaces:**\\n\\n```bash\\n# creates a namespace \\"tenant\\" on root-level\\n$ bao namespace create tenants\\n# creates a child-namespace within tenants\\n$ bao namespace create -ns tenants tenant-c\\n# creates a child-namespace within tenants/tenants-c\\n$ bao namespace create -ns tenants/tenant-c prod\\n```\\n\\nNote how we use the `-ns` (short form for `-namespace`) flag to create a child-namespace `tenant-c` within the namespace `tenant`. To view status and metadata, we can utilize the `lookup` command:\\n\\n```bash\\n$ bao namespace lookup -ns tenants/tenant-c prod\\nKey Value\\n--- -----\\ncustom_metadata map[]\\nid 8QujqL\\npath tenants/tenant-c/prod/\\ntainted false\\nuuid f06d10c7-1300-6c4d-8616-c203b5fdf705\\n```\\n\\nFurthermore, we can easily enumerate our hierarchy of namespaces by using the `scan` subcommand.\\n\\n```bash\\n$ bao namespace scan\\nKeys\\n----\\ntenants/\\ntenants/tenant-c/\\ntenants/tenant-c/prod/\\n```\\n\\n2. **Create Resources within Namespaces**\\n\\nSince the introduction of Namespaces, many OpenBao commands have become namespace-aware. Similar to our example before, we can add `-namespace` or in short `-ns` to the command.\\n\\nFor demonstration purposes, let\'s create a KV secrets engine and populate it with a secret.\\n\\n```bash\\n$ bao secrets enable -ns=tenants/tenant-c/prod -description=\\"Production Secrets\\" kv\\nSuccess! Enabled the kv secrets engine at: kv/\\n```\\n\\nNow that we have created a new kv secrets engine, it will be listed among our default engines:\\n\\n```bash\\n$ bao secrets list -ns tenants/tenant-c/prod\\nPath\xa0 \xa0 \xa0 \xa0 \xa0 Type\xa0 \xa0 \xa0 \xa0 \xa0 \xa0 Accessor\xa0 \xa0 \xa0 \xa0 \xa0 \xa0 \xa0 Description\\n----\xa0 \xa0 \xa0 \xa0 \xa0 ----\xa0 \xa0 \xa0 \xa0 \xa0 \xa0 --------\xa0 \xa0 \xa0 \xa0 \xa0 \xa0 \xa0 -----------\\ncubbyhole/\xa0 \xa0 ns_cubbyhole\xa0 \xa0 cubbyhole_9a4e44d3\xa0 \xa0 per-token private secret storage\\nidentity/ \xa0 \xa0 ns_identity \xa0 \xa0 identity_61c42408 \xa0 \xa0 identity store\\nkv/ \xa0 \xa0 \xa0 \xa0 \xa0 kv\xa0 \xa0 \xa0 \xa0 \xa0 \xa0 \xa0 kv_b993bbec \xa0 \xa0 \xa0 \xa0 \xa0 Production Secrets\\nsys/\xa0 \xa0 \xa0 \xa0 \xa0 ns_system \xa0 \xa0 \xa0 system_ba514ba2 \xa0 \xa0 \xa0 system endpoints used for c
1ontrol, policy and debugging\\n```\\n\\nLet\'s read and write a secret...\\n\\n```bash\\n# Create the secret within namespace\\n$ bao kv put -namespace=tenants/tenant-c/prod -mount=kv auth-token foo=bar\\nSuccess! Data written to: kv/auth-token\\n\\n# Read it\\n$ bao kv get -namespace=tenants/tenant-c/prod -mount=kv auth-token\\n=== Data ===\\nKey\xa0 \xa0 Value\\n---\xa0 \xa0 -----\\nfoo\xa0 \xa0 bar\\n```\\n\\n3. **Lifecycle Operations**\\n\\nOver time, tenants will inevitably require various changes and customizations to their namespaces. Moving the administration away from the OpenBao operators means that the tenant operator can perform those changes on demand and individually. Consequently, we implemented the associated (and probably expected) lifecycle features such as:\\n\\n* Namespace-aware policies and quotas\\n* Moving or renaming secret or auth engines across namespaces\\n* Locking and unlocking of namespaces\\n\\nWhile we have many plans on extending namespace capabilities in the future to make them even more helpful, we still maintain API compatibility with Vault Enterprise to enable a smooth migration path.\\n\\n## Looking Ahead: Horizontal Scalability\\n\\nNamespaces will give organisations the possibility to better structure and isolate secret information. However, the introduction of namespaces is just the first step. Our vision includes supporting _lazy loading_ of namespaces and mounts, allowing OpenBao clusters to efficiently serve workloads with many infrequently accessed resources. This will enable even greater scalability and resilience, as nodes will no longer need to load the entire system state at once. \\n\\n[Here](/blog/vision-for-namespaces/) is another article that you can read more about OpenBaos\' scalability efforts. Sounds interesting? Reach out to the project via [Github](https://github.com/orgs/openbao/discussions), [Zulip](https://github.com/openbao#contact), or [Mailinglist](https://lists.openssf.org/g/openbao) if you want to support our work in the areas of namespaces or scalability.\\n\\n## Get Started\\n\\nWe just carved a beta release of [OpenBao 2.3](https://github.com/openbao/openbao/releases/tag/v2.3.0-beta20250528). We encourage you to explore the new features and share your feedback as we continue to improve OpenBao as a
1secure, scalable, and self-service secrets management solution.\\n\\nLooking ahead, the namespaces working group is actively exploring improvements such as namespace sealing, non-hierarchical namespaces, per-namespace storage backends, and plugin isolation. These efforts aim to make namespace usage more flexible, efficient, and secure in future releases.\\n\\nWe welcome contributions from individuals and organizations, whether helping to improve documentation, clarifying existing content, or contributing to upcoming features. Your input plays a vital role in shaping the future of OpenBao."},{"id":"edgex-selects-openbao","metadata":{"permalink":"/blog/edgex-selects-openbao","source":"@site/content/blog/2025-03-18-edgex-selects-openbao.md","title":"OpenBao Adopted as the Secret Store for EdgeX Foundry","description":"Why EdgeX chose OpenBao for its critical secret storage","date":"2025-03-18T00:00:00.000Z","tags":[{"inline":true,"label":"announcement","permalink":"/blog/tags/announcement"},{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"collaboration","permalink":"/blog/tags/collaboration"}],"readingTime":2.12,"hasTruncateMarker":true,"authors":[{"name":"James Butcher","url":"https://www.linkedin.com/in/james-butcher-15698115","socials":{"linkedin":"https://www.linkedin.com/in/james-butcher-15698115"},"key":"JamesButcher","page":null}],"frontMatter":{"title":"OpenBao Adopted as the Secret Store for EdgeX Foundry","description":"Why EdgeX chose OpenBao for its critical secret storage","slug":"edgex-selects-openbao","authors":"JamesButcher","tags":["announcement","community","collaboration"],"image":"https://www.edgexfoundry.org/cmsfiles/image/company-logo-lg.png"},"unlisted":false,"prevItem":{"title":"Announcing OpenBao Namespaces","permalink":"/blog/namespaces-announcement"},"nextItem":{"title":"Vision for Namespaces, Horizontal Scalability","permalink":"/blog/vision-for-namespaces"}},"content":"Great news for the OpenBao community! In a major step towards enhancing its own security and openness, EdgeX Foundry has officially adopted OpenBao as its default secret store for the EdgeX 4.0 release.\\n\\n## What is EdgeX Foundry?\\nFor those unfamiliar, [EdgeX Foundry](https://www.edgexfoundry.org/) is an open-source, IoT/edge computing framework hosted by the Linux Foundation. It\u2019s designed to enable seamless communication between devices, applications and services using a flexible, microservices-based architecture. Whether you\u2019re working in automation, energy, or building management, EdgeX helps bring everything together in a standardized way.\\n\\n\\n\\n\x3c!-- truncate --\x3e\\n\\n## The Need for Secret Storage\\nSecurity is a top priority in EdgeX, and managing secrets\u2014like API keys, passwords, and certificates\u2014is crucial. Instead of reinventing the wheel, EdgeX has always integrated third-party open-source solutions for secret management. Until now, it relied on HashiCorp Vault for securely storing sensitive information.\\n\\nHowever, with Vault moving to a Business Source License (BSL), the EdgeX community wanted to consider an alternative going forward. That\u2019s where OpenBao comes in.\\n\\n## The Role of OpenBao\\nOpenBao is a community-driven, open-source project under the Linux Foundation. It provides an identity-based secrets and encryption management system, ensuring sensitive data stays protected. Since it shares a strong foundation with Vault, OpenBao makes for a natural transition.\\n\\n## Why OpenBao?\\nAdopting OpenBao brings several advantages to EdgeX Foundry, including:\\n\\n\u2705 Seamless Migration \u2013 OpenBao is designed to be API compatible with its upstream, making the switch smooth and hassle-free.\\n\\n\u2705 Open & Vendor-Neutral Licensing \u2013 open-source freedom and long-term community collaboration.\\n\\n\u2705 Security-First Approach \u2013 Strong encryption and identity-based access controls keep secrets safe.\\n\\n\u2705 Active Community Support \u2013 A dedicated team ensures ongoing improvements, security updates and feature enhancements.\\n\\n## What this means for EdgeX Users\\nIf you\u2019re already using EdgeX, this change should be practically seamless. The Core Services have been updated to work with OpenBao while keeping the same APIs as before, meaning minimal disruption. You\u2019ll still manage secrets securely, with the added benefit of an actively maintained and community-driven solution.\\n\\n## Looking Ahead\\nThe move to OpenBao reflects EdgeX Foundry\u2019s ongoing dedication to security, transparency, and open-source collaboration. With EdgeX 4.0 (codenamed Odesa) now released, it is the perfect time to explore OpenBao, share feedback, and get involved in shaping its future.\\n\\nStay tuned for more updates on OpenBao and [keep in touch with EdgeX](https://github.com/orgs/edgexfou
1ndry/discussions) and related commercial products, as they enjoy the benefits of security and openness with OpenBao going forward!"},{"id":"vision-for-namespaces","metadata":{"permalink":"/blog/vision-for-namespaces","source":"@site/content/blog/2025-02-26-vision-for-namespaces.md","title":"Vision for Namespaces, Horizontal Scalability","description":"Description of Alex\'s vision for how Namespaces and Horizontal Scalability can improve OpenBao","date":"2025-02-26T00:00:00.000Z","tags":[{"inline":true,"label":"vision","permalink":"/blog/tags/vision"},{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"technical","permalink":"/blog/tags/technical"}],"readingTime":7.3,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Vision for Namespaces, Horizontal Scalability","description":"Description of Alex\'s vision for how Namespaces and Horizontal Scalability can improve OpenBao","slug":"vision-for-namespaces","authors":"cipherboy","tags":["vision","community","technical"]},"unlisted":false,"prevItem":{"title":"OpenBao Adopted as the Secret Store for EdgeX Foundry","permalink":"/blog/edgex-selects-openbao"},"nextItem":{"title":"OpenBao @ GitLab - FOSDEM \'25","permalink":"/blog/cipherboy-fosdem-25-talk"}},"content":"As the OpenBao community [starts development on Namespaces](https://github.com/openbao/openbao/issues/787)\\nand the Horizontal Scalability Working Group has its kickoff, I wanted to take\\nthe opportunity to put forward a blog post describing how these two groups\'\\nwork can compliment each other and provide an alternative path forward other\\nthan Vault Enterprise\'s Performance Secondary and Disaster Recovery clustering\\nmodes.\\n\\n\x3c!-- truncate --\x3e\\n\\n## Scaling Read Operations\\n\\nMost obviously, the first step for the Horizontal Scalability working group\\nwill be to [allow standby nodes to service requests](https://github.com/openbao/openbao/issues/569)\\nas described in our project direction & roadmap:\\n\\n> 4. Allow HA standby nodes to service read-only (from a storage modification PoV) requests. (scalability)\\n> - Currently HA mode standby nodes forward all requests up to the active node, preventing horizontal scalability of OpenBao. Due to limitations in Raft (only the active node can perform storage writes), we can\'t immediately scale writes. Thus, start by bringing these nodes \\"online\\" (loading the mount table, plugins, &c) and allowing them to service read-only requests, returning `ErrReadOnly` on storage write operations to trigger automatic request forwarding.\\n\\nThe shortcoming of this is that writes are not scalable: there is still only\\na single active writer node. Note that a read operation in this context refers\\nto any API request (of any operation type) that results only in `get` or `list`\\n(\\"read\\") storage operations. Any operations involving a storage write (`put`\\nor `delete`) would be forwarded to the active node for processing.\\n\\nThis behaves similarly to Performance Secondary Standby nodes.\\n\\n## Scaling Write Operations\\n\\nIn our RFC for namespaces, there is the following future work item:\\n\\n> ### Per-Namespace Storage Segments\\n>\\n> At the physical storage level, a namespace could be implemented as a new database schema in PostgreSQL (with each plugin being a new database table) or a new disk directory in Raft/BoltDB. This can likely build on top of storage views, using the existing JSON namespace data to translate source path to destination. This would help with scaling OpenBao: each tenant would have its own data storage location and so could impact other tenants less. Theoretically this could even lead to per-segment unique storage backend depending on workload characteristics assuming no cross-segment consistency is required.\\n>\\n> However, this work is strictly disjoint from implementing namespaces as a feature and so will be done later.\\n\\nIn conjunction with additional changes to horizontal scalability, this change\\ncould allow each namespace to have a different active node dictated by its\\nstorage backend, distributing writes across the cluster. Notably, very few\\noperations are truly cross-namespace; this is mostly limited to the creation\\nand deletion of namespaces and mount move operations, which affects the\\nnamespace store in the parent context in addition to the actual target\\nnamespace.\\n\\nThe benefit of this approach is that it doesn\'t affect plugins, token stores,\\nACL stores, or any other namespace-specific functionality. This is because\\nour namespace design opted to place all namespace-specific data within the\\nnamespace\'s path (`/namespaces/<uuid>`) rather than mixing it within the\\nroot of storage (`/core` or `/sys`) across all namespaces.\\n\\nAdditionally, this gives a natural place for segmenting storage, allowing\\nsmaller databases when used with PostgreSQL or Raft. This allows greater\\nscalability as many have scalability problems when lots of data is written\\nto a single backend instance. By supporting different storage types (e.g.,\\nmixing and matching PostgreSQL and Raft), namespaces with different SLA
1s\\nor workload write/read ratios can be supported.\\n\\nOne shortcoming with this approach is it doesn\'t allow scaling all types of\\nworkloads. For instance, a single PKI mount which stores certificates will\\nnot be horizontally scalable as writes will not be able to be distributed.\\nHowever, the majority of large, diverse workloads will be able to be\\ndistributed because of this change.\\n\\nAnother shortcoming is the complexity this entails for an operator. Some\\nof this may be mitigated by allowing namespace-native configuration, without\\nrequiring full configuration file changes.\\n\\n## Disaster Recovery\\n\\nOpenBao recently added support for [Raft non-voter nodes](https://github.com/openbao/openbao/issues/578).\\nThis can likely form the basis of [disaster recovery](https://github.com/openbao/openbao/issues/38),\\nespecially if enablement for other storage backends (like PostgreSQL) is\\nadded.\\n\\nNotably in Raft, non-voter status means that these nodes do not contribute to\\nquorum requirements, allowing writes to commit faster but still allowing the\\nuse of Raft to distribute updates. This means that adding non-voter nodes\\nresults in additional traffic from the leader but doesn\'t otherwise impact\\nwrite speeds. By putting these non-voters in secondary data centers, with\\n[the ability to promote non-voter nodes](https://github.com/openbao/openbao/pull/996),\\nwe can subsequently initiate a failover operation in the event the primary\\ncluster goes down, with minimal data loss.\\n\\nPostgreSQL can similarly be extended to support a non-voter setup, wherein\\ncertain nodes will not attempt to become leaders unless updated later. This\\nwill behave similarly to Raft, allowing more read scalability via the use of\\nread-only PostgreSQL replicas in other secondary data centers.\\n\\nBy broadening [the use of transactions](https://github.com/openbao/openbao/issues/607),\\nwe can further guarantee that these other nodes are consistent, independent\\nof what storage backend is used.\\n\\nAdditionally, we could allow standby or non-voter nodes to serve read requests\\nwithout an active leader. This could potentially be extended to support\\ngenerating offline authentication tokens using JWTs or similar signature-based\\nschemes for use with non-lease paths. This would allow for greater high\\navailability in the event of a leadership outage.\\n\\n## Offline Recovery Mode\\n\\nSometimes a hybrid replication mode would be preferred; Vault Enterprise\\nsupports this via a [path filtering operation](https://developer.hashicorp.com/vault/api-docs/system/replication/replication-performance#create-paths-filter).\\n\\nWhen we combine the [earlier work for per-namespace storage backends](#scaling-write-operations)\\nwith an additional Namespaces future work item:\\n\\n> ### Per-Namespace Seal Mechanisms\\n>\\n> The existing Vault Enterprise Namespace feature supports locking and unlocking namespaces by an operator with access to the parent namespace. While potentially useful to limit requests to a namespace without impacting other users, we could add a similar mechanism using the Barrier + Keyring functionality to also give us per-tenant encryption. This also lets the tenant control their own encryption keys. With lazy loading of namespaces (preventing inbound requests unless the namespace is unsealed), this behaves similarly to locking and unlocking the namespace though doesn\u2019t conflict with it.\\n>\\n> However, this work is strictly disjoint from implementing namespaces as a feature and so will be done later.\\n\\nIf we implement non-hierarchical namespaces, which do not chaining to `root`\\nas a parent for tokens, ACL policies, or layered sealing, this allows us to\\nhave cluster-independent namespaces. We would additionally need the Shamir\\nfallback [from the parallel unseal RFCs](https://github.com/openbao/openbao/issues/1021).\\n\\nThis gives two nice properties:\\n\\n1. We can have a stronger path filtering, allowing replication of namespaces\\n in disjoint cluster topologies. For instance, a secondary site may have only\\n a subset of namespaces, which it may be non-voter on until promoted to\\n leader during an outage.\\n2. A namespace could potentially be shared by two different organizations as\\n a form of secret sharing with some peer establishment protocol.\\n\\nNotably, the parallel unseal allows either Shamir\'s based initial\\nestablishment or the use of public keys explicitly provisioned for local-only\\nseal material usable by the remote cluster. This allows local disaster nodes\\nto survive the outage of the primary seal mechanism.\\n\\n## Lazy Loading\\n\\nBy making Namespaces have their own seal mechanism, we\'ll be forcing OpenBao\\nto handle the scenario when a namespace cannot be loaded. We have two options:\\n\\n1. To hard fail, requiring operators to rectify the problem immediately. With\\n things like parallel unseal, this should be doable unless a storage engine\\n itself is down.\\n2. To soft fail, refusing to load the namespace (and any children) but\\n continuing regular operation on all other namespaces.\\n\\nThis sits on different sides of a security/availability problem: we could be\\navailable, but not processing key revocations because a single namespace is\\noffline, or we could be in a similar place, not processing all revocations\\nbecause a single offline namespace resulted in all namespaces being\\nunavailable.\\n\\nI\'d like to see namespaces, and eventually mounts, be lazily loadable. This\\nwill likely require new interfaces for backends to indicate when they\'d next\\nlike their Rollback function to be issued, if that occurs too infrequently.\\nAnd mounts will need to be audited for lease expiry, with some window for\\nmount reuse without unmounting refreshed on last request.\\n\\nBut, this will allow us to scale OpenBao to workloads with lots of\\ninfrequently-accessed mounts without requiring all nodes in a cluster have\\nthe capability of loading the entire system at once."},{"id":"cipherboy-fosdem-25-talk","metadata":{"permalink":"/blog/cipherboy-fosdem-25-talk","source":"@site/content/blog/2025-02-12-cipherboy-fosdem-25-talk.md","title":"OpenBao @ GitLab - FOSDEM \'25","description":"Blog of Alex\'s talk at FOSDEM \'25, describing the usage of OpenBao at GitLab","date":"2025-02-12T00:00:00.000Z","tags":[{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"conferences","permalink":"/blog/tags/conferences"},{"inline":true,"label":"talks","permalink":"/blog/tags/talks"}],"readingTime":12.26,"hasTruncateMarker":true,"authors":[{"name":"Alex Sc
1heel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao @ GitLab - FOSDEM \'25","description":"Blog of Alex\'s talk at FOSDEM \'25, describing the usage of OpenBao at GitLab","slug":"cipherboy-fosdem-25-talk","authors":"cipherboy","tags":["community","conferences","talks"]},"unlisted":false,"prevItem":{"title":"Vision for Namespaces, Horizontal Scalability","permalink":"/blog/vision-for-namespaces"},"nextItem":{"title":"OpenBao Travels Back Home","permalink":"/blog/bao-back-home"}},"content":"Slides and content from Alex\'s [FOSDEM \'25 talk](/blog/fosdem-25) about OpenBao\'s usage at GitLab.\\n\\nFor a video, see our [official YouTube channel](https://youtu.be/V50hdX2d8IA) or [on the FOSDEM video mirror](https://video.fosdem.org/2025/ua2118/fosdem-2025-5145-openbao-at-gitlab-building-native-secrets-for-gitlab-ci-cd-pipelines.av1.webm).\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-01.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nHello everyone! I\'m Alex Scheel, a Staff Backend Engineer at GitLab and Chair of the OpenBao Technical Steering Committee. I\'m here to talk about OpenBao and its usage at GitLab.\\n\\n\x3c!-- truncate --\x3e\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-02.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\nTo get started, the most important question is, \\"What is OpenBao\\"?\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-03.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nOpenBao is a fork of HashiCorp Vault, remaining under the original Mozilla Public License, with open governance under the Linux Foundation\'s LF Edge subproject.\\n\\nIt is an advanced secrets manager supporting four categories of features:\\n\\n1. _Static secrets_, provisioned by users directly and securely stored.\\n2. _Dynamic secrets_, automatically generated on-demand to integrate with things like databases or cloud provider identities.\\n3. _Encryption services_, supporting PKI or SSH certificate creation and KMS-like encryption-as-a-service functionality.\\n4. And lastly, _Sync, Visibility, and Management_ of these secrets: integrations with Kubernetes External Secret Operator, Cert-Manager, and a custom templating agent to handle last-mile delivery of secrets. All of this comes with detailed audit logs tracking access to the system.\\n\\nA secrets manager is, to organizations and developers writing applications, what a password manager is for humans.\\n\\nOpenBao is API-driven and highly flexible. It supports many different authentication engines, from OIDC and Kubernetes to LDAP and Kerberos, and creating or storing many types of identities, letting it function as an _identity broker_.\\n\\nThe goal is to trade-off a little bit of _operational risk_ -- one more, admittedly complex, service to run -- to greatly lessen the _security risk_ of compromise: you can enforce a healthy secrets posture to ensure that rotation and revocation of sensitive credentials are possible, limiting your organization\'s exposure window in the event of compromise.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-04.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nWhile a complete timeline of OpenBao would take a while, there\'s a few important events I want to highlight:\\n\\n - HashiCorp first released Vault in April of 2015, so there has been nearly a decade of work on it.\\n - In August of 2023, HashiCorp announced that they\'d be relicensing their products under the non-OSI Business Source License (violating freedom zero); this triggered the early fork of Terraform into OpenTofu, our sister project also under the Linux Foundation.\\n - The fork of Vault by IBM Software came much later, in November of that year, and kept with the naming convention. Unlike OpenTofu, which was made up of many member companies which sponsored full-time development, OpenBao has been more of a grass-roots, community effort.\\n - We\'ve done 8 releases -- two major and six bug fixes, shipped several core improvements, and put together our Technical Steering Committee and governing documents.\\n - My employer, GitLab, joined the project officially in July and achieved voting status in October of last year. To the best of my knowledge, I\'m incredibly fortunate to be one of the few people employed to work on OpenBao full time.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-05.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nOne of the things you might be asking is, OK, it is another fork of a HashiCorp product. What\'s different about this one?\\n\\nWhile OpenBao remains in the spirit of the original project, we\'ve made a few changes to make it easier to maintain and contribute:\\n\\n1. We started with a reduced base, removing many components that an open-source group with no formal funding could not support. That meant making hard choices around storage backends -- Raft and n
1ow PostgreSQL are the only supported two -- but also the removal of proprietary cloud integrations for authentication and dynamic secrets for the time being. We hope to revive especially the cloud auth and secret plugins as we get more funding and interest.\\n2. Using that space, we\'ve made core technological improvements to the storage subsystem--paginated lists and transactions--which in turn allowed us to improve scalability. These improvements were directly made possible by removing every single storage backend but Raft. We hope these types of improvements will continue after we add APIs for additional external, community-provided storage plugins, so that we can make long-term improvements to upcoming features like namespaces and horizontal scalability.\\n2. Lastly, we\'ve set up an open organization with clear contribution and project leadership processes. Our RFC process is open to anyone to draft designs and propose major or minor changes to the architecture or project. We\'ve started a community mentorship program, helping two individuals with different familiarity with OpenBao to contribute. But throughout this, we continued under the original MPL license.\\n\\nIn short, my personal vision for where I hope OpenBao can go is to build an ecosystem similar to Kubernetes: companies large and small, and individuals experienced or just starting out, can contribute to the project and find market segments to provide derivative offerings while contributing to a common code base.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-06.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nNext, you might be asking \\"why GitLab\\"?\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-07.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nFor a while, GitLab has been focused on building a more complete DevSecOps platform.\\n\\nA common problem our customers face is managing secrets in their CI/CD Pipelines. Today, they have one of two options:\\n\\n1. They can use masked variables. These have very few controls over the scope of access and customers can\'t easily differentiate in the dashboard between secrets and inconsequential data, though all are stored encrypted at rest. A few customers have many thousands of variables and the difference in ideal behavior differs substantially between the two use cases for them. No one solution will really work for both.\\n2. Instead, many customers turn to our external integrations with various other secret management providers. However, the user experience isn\'t quite there: one typically has to work across several teams to enable OIDC ID Token authentication so pipelines can access secrets and the customer must organize the logistics of secret storage and rotation. Because GitLab plays a very minor role, mostly by providing identity to the pipelines, it lacks visibility into the actual secrets and the hierarchy administrators have set up.\\n\\nIn short, there is no easy-to-use, per-project dashboard for secrets and neither approach can provide this easily. And many times, a developer has to find many individuals in their organization with permissions to do one of these steps in order to onboard their new project.\\n\\nIn late 2023, GitLab started working on this problem, building their own design from the ground up. In May, my colleague, Jocelyn, published this in a blog post, considering the use of OpenBao to solve this problem.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-08.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nOpenBao is a great choice for GitLab because we already support a HashiCorp Vault integration. For Premium and Ultimate tier customers, the Pipeline runner features native integration for fetching secrets from Vault: while all GitLab versions support issuing the OIDC ID Tokens, these paid plans offer support for a simplified pipeline syntax, improving the developer experience over manual CLI calls to Vault.\\n\\nBeing a mature secrets management solution already, OpenBao brings several useful properties to GitLab:\\n\\n1. It has already been deployed at scale by various entities.\\n2. It has historically undergone audits and certifications useful for enterprise customers.\\n3. It is a self-contained service, which we can isolate from the rest of our environment and treat as trusted.\\n\\nWhat we\'d like to do is provide a single dashboard which lets us aggregate information into a project-specific view of secrets. Whereas previously audit logs might be separate between GitLab and a backend Vault instance, we can correlate them natively within the GitLab UI. Or, where access controls required understanding two separate permissions models--that of GitLab and that of Vault\'s ACL policies--GitLab will translate its own roles into OpenBao policies on behalf of the user.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-09.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nAt its core, our architecture is just like it was before, but with OpenBao replacing HashiCorp Vault and moving it from the customer\'s deployment to our management scope. It remains a separate service that pipeline workers talk to and customers will eventually be able to bring their own KMS to secure key material as well.\\n\\nWhat is new is the interactions, typically driven by a user, between Rails and OpenBao for management purposes. When a user initiates any secrets management\\nrequest, they do so via GitLab\'s Rail\'s API, which enforces initial authentication and holds privileged tokens for ACL management. In the future, we seek to add a User JWT issuer, allowing direct secret write operations by users without invoking Rails.\\n\\nWe thus get a clean trust separation, between three different entities:\\n\\n1. GitLab Rails, which will perform various administrative actions on behalf of users,\\n2. Pipelines, which will execute jobs and fetch secrets, and\\n3. OpenBao, which is the source of truth for authorization and secret storage.\\n\\nWith official PostgreSQL support, OpenBao will be able to use the same database as Rails for smaller self-managed GitLab instances, avoiding the complexities of managing Raft which come with running Vault. Data will be encrypted before storing it in PostgreSQL and requires ke
1ys from a seal mechanism to decrypt.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-10.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nThe key to integrating OpenBao is to be opinionated about its data storage layout. Philosophically, OpenBao aligns with key/value databases: its API path structure usually mirrors the underlying data storage. ACL policies are groups of grants to specific capabilities\u2013like read, write, delete\u2013on specific API paths, with a default deny rule. After authentication, perhaps via a third-party engine, OpenBao issues a token, mapping an identity to a set of ACL policies. Thus, there is no concept of a long-term identity which has ownership of a secret.\\n\\nThe core of our design to integrate with OpenBao is a data layout which provides multi-tenancy and isolation of secrets. This architecture is familiar to many of our customers who have successfully integrated with their HashiCorp Vault cluster
1s.\\n\\nEach top-level tenant, usually the owner of a repository, has a separate path area in OpenBao. Within this space, they have an authentication mount for authorizing pipeline\'s access to secrets, with roles corresponding to each project. Each project has its own KVv2 secrets engine for storing that project\'s secrets, which contains custom metadata indicating the scope and contextual information like description.\\n\\nGitLab Rails can read this metadata and provision ACL policies and JWT roles for all scopes when changes are necessary.\\n\\nWhen support for Namespaces lands upstream, we\'ll seek to provision each tenants into their own namespaces and, long-term, we wish to use unique encryption keys with separate seal mechanisms to provide greater data isolation on GitLab.Com via per-tenant encryption keyrings.\\n\\nWithin the core management space is another authentication mount for authorizing Rail\'s own requests into OpenBao. The core of these requests are for provisioning new tenants and their mounts but also being the trusted entity that maintains the ACL policies. These ACL policies reflect the permissions and scopes of access designated by users for accessing these secrets: each environment or branch for a project is a separate policy, which contains read access to secrets within that scope.\\n\\nAuthentication occurs via a properties based model. OIDC ID Tokens issued by GitLab to pipeline jobs have claims reflecting contextual metadata, such as the repository, branch, initiating user, and environment. Each tenant\'s JWT mount matches these claims to a per-project role, with dynamic generation of ACL policies based on the properties present on the token.\\n\\nUniquely, this model lets us use OpenBao as the single source of truth for all operations: permissions are reflected via ACL roles, scopes and context are present in contextual metadata, and Rails is only present as a management engine and a trusted token issuer and pipeline provisioner and does not store data of its own.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-11.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nSo from a developer\'s perspective, all this work leads to the following two actions to use secrets in their pipelines:\\n\\n1. Create a new secret via the native GitLab UI, specifying the scope of access and its value.\\n2. Access the secret from a pipeline\'s `.gitlab-ci.yml` definition file, using the secret name as the reference key.\\n\\nAnd GitLab Rails and OpenBao will handle the rest.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-12.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nAt GitLab, we\'ve been really excited about using OpenBao. If you are too, we welcome contributors of any sort! You can check out our roadmap, join our weekly community calls, or talk about OpenBao on social media or at conferences.\\n\\nIf you\'re a customer interested in the work GitLab is doing to build our native pipeline secrets solution, ask your account team about joining our beta program.\\n\\n---\\n\\n<object type=\\"image/svg+xml\\" data=\\"/img/talks/cipherboy-fosdem-25/OpenBao-at-GitLab-Slide-13.svg\\">\\nSVG rendering is not supported on your browser.\\n</object>\\n\\n\\nI\'m happy to take questions now, but if you have any additional questions or want stickers or a picture with our cute mascot, BaoBao, find me afterwards in person or online!"},{"id":"bao-back-home","metadata":{"permalink":"/blog/bao-back-home","source":"@site/content/blog/2025-02-07-bao-back-home.md","title":"OpenBao Travels Back Home","description":"OpenBao\'s travels back home","date":"2025-02-07T00:00:00.000Z","tags":[{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"conferences","permalink":"/blog/tags/conferences"},{"inline":true,"label":"stickers","permalink":"/blog/tags/stickers"}],"readingTime":2.27,"hasTruncateMarker":true,"authors":[{"name":"Alex Sc
1heel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao Travels Back Home","description":"OpenBao\'s travels back home","slug":"bao-back-home","authors":"cipherboy","tags":["community","conferences","stickers"],"image":"/img/alex-fosdem-25-speaking.jpg"},"unlisted":false,"prevItem":{"title":"OpenBao @ GitLab - FOSDEM \'25","permalink":"/blog/cipherboy-fosdem-25-talk"},"nextItem":{"title":"OpenBao Travels to FOSDEM","permalink":"/blog/bao-at-fosdem-25"}},"content":"OpenBao returns from FOSDEM \'25 and OpenUK\'s State of Open Con this week,\\nreflecting on the travels and activities of the events.\\n\\nMany thanks to Fatima for running the [community calls](/community/contributing/)\\nin our absence!\\n\\n\\n\\n_photo credit: nicolas; pictured: alex_\\n\\nFOSDEM \'25 was Alex\'s first time speaking at a conference and we are happy to\\nreport it was a success! The details of the talk were saved and will be\\npublished in a follow-up blog along with the recording when it is made\\navailable from the conference. It was great to meet so many people interested\\nin identity and access management and OpenBao\'s role in solving secrets\\nmanagement problems, at GitLab and beyond.\\n\\n\x3c!-- truncate --\x3e\\n\\n\\n\\nAfter arriving in London, BaoBao was happy to find the conference venue was\\nvery well organized and everything was ready. And look, our logo is situated\\nnicely on the list of table holders! BaoBao thanks OpenUK for generously\\nsponsoring OpenBao\'s attendance this year and hopes to participate in the\\nfuture.\\n\\n\\n\\nDuring setup, BaoBao took a place on the table to get ready for the next two\\
1ndays of meeting people. When [OpenTofu](https://opentofu.org/) couldn\'t make\\nit, Alex volunteered to represent them as well, which served as a great\\nconversation starter. BaoBao knows that they\'d do the same, after all, we\'re\\nboth OpenHashiForks!\\n\\n\\n\\nAfter meeting the kind folks from [Percona](https://www.percona.com/) at\\nFOSDEM, we encountered them again at State of Open, where they played hijinks\\nwith BaoBao! When Alex wandered off, they bestowed upon BaoBao a\\n[Valkey](https://valkey.io/) hat -- [a good reminder to revive and rename our\\nsecrets engine](https://github.com/openbao/openbao/issues/965)! BaoBao\\nappreciated the effort to avoid feeling chilly in the big conference center.\\n\\n\\n\\nLater, [OSA Con](https://osacon.io) joined in the fun, placing a warning\\nsticker that this booth talked too much about open source... BaoBao thought\\nthis disclaimer was much needed!\\n\\n\\n\\n_photo credit: nigel; pictured: alex and dotan_\\n\\nFinally, BaoBao and Alex got to meet [Dotan Horovits](https://www.linkedin.com/posts/horovits_stateofopencon-openbao-soocon25-activity-7292823212332085248-U4Bh?utm_source=share&utm_medium=member_desktop),\\nthe CNCF Ambassador who made the necessary connections to get OpenBao\\ninvited to State of Open Con!\\n\\nBoth Alex and BaoBao had lots of fun networking and making friends\\nwith fans of OpenBao. Thank you to everyone who organized these events and\\nhelped them run so smoothly! A special thanks to all who offered to support\\nOpe
1nBao or consider it for use in their company!"},{"id":"bao-at-fosdem-25","metadata":{"permalink":"/blog/bao-at-fosdem-25","source":"@site/content/blog/2025-01-31-bao-at-fosdem.md","title":"OpenBao Travels to FOSDEM","description":"OpenBao\'s travels to FOSDEM \'25","date":"2025-01-31T00:00:00.000Z","tags":[{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"conferences","permalink":"/blog/tags/conferences"},{"inline":true,"label":"stickers","permalink":"/blog/tags/stickers"}],"readingTime":2.15,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao Travels to FOSDEM","description":"OpenBao\'s travels to FOSDEM \'25","slug":"bao-at-fosdem-25","authors":"cipherboy","tags":["community","conferences","stickers"],"image":"/img/baobao-fosdem-25-airplane.jpg"},"unlisted":false,"prevItem":{"title":"OpenBao Travels Back Home","permalink":"/blog/bao-back-home"},"nextItem":{"title":"OpenBao at FOSDEM, State of Open Con!","permalink":"/blog/fosdem-25"}},"content":"Follow along with OpenBao\'s travels this week as we attend FOSDEM \'25 and\\nState of Open Con!\\n\\n:::info\\n\\nCheck out [Alex\'s talk at FOSDEM](https://fosdem.org/2025/schedule/event/fosdem-2025-5145-openbao-at-gitlab-building-native-secrets-for-gitlab-ci-cd-pipelines/),\\non Sunday, February 2nd, at 2:05 PM GMT+1 in room UA2.118 (Henriot) as part\\nof the Identity and Access Management track.\\n\\nIf you can\'t attend in person, it will also be [live streamed](https://live.fosdem.org/watch/ua2118).\\n\\n:::\\n\\n\\n\\nFrom snowy Minnesota, [BaoBao](/blog/fosdem-25/) took its\\nfirst ride to London Heathrow to begin its voyage to FOSDEM \'25. With a brief\\nlayover, it explored King\'s Cross and the Coal Drops Yard. Rich with history,\\nthis area has long been used as a rail hub for the UK and now is connected to\\nEurope via the Channel Tunnel.\\n\\n\x3c!-- truncate --\x3e\\n\\n\\n\\nFrom there, BaoBao boarded a train to Paris, France for some sightseeing and\\nmeetings with community members. BaoBao wishes that secrets management was as\\neasy as traveling via European trains, but, with the help of the community,\\nknows it will improve!\\n\\nFirst up, the Eiffel Tower!\\n\\n\\n\\n\\nWhile it was rainy and dark, seeing the structure all lit up in person was\\nvery impressive! BaoBao thought the structure loomed larger than life, just\\nlike attackers in the shadows, targeting deployments using insecure secrets\\nmanagement practices...\\n\\n\\n\\nThe next day, BaoBao explored Paris a bit more, visiting the Notre Dame, the\\nPantheon, and finally, the Louvre! One of the largest museums in the world,\\nfilled with all types of art, from paintings to sculptures to fashion, this\\nmuseum would take several visits to fully appreciate. BaoBao thinks there\'s\\nart to open source too, and wishes it would be in its own museum some day!\\n\\n\\n\\nBaoBao went out for dinner with its colleagues, Julien Cassignol (right),\\nOpenBao TSC representative and CTPO of Wallix, and Dan Ghita (left),\\nOpenBao Maintainer and backup Viaccess-Orca representative. BaoBao thinks\\nits favorite part of open source is the friends you make along the way.\\n\\n\\n\\nOn Friday, BaoBao took the train from Paris to Brussels to join the fun that\\nis FOSDEM. At dinner with friends old and new, BaoBao met Jan Martens, OpenBao\\nMaintainer.\\n\\nAnd now, BaoBao rests for the conference ahead -- and hopes to see you there!"},{"id":"fosdem-25","metadata":{"permalink":"/blog/fosdem-25","source":"@site/content/blog/2025-01-16-fosdem.md","title":"OpenBao at FOSDEM, State of Open Con!","description":"OpenBao will be at FOSDEM \'25 and SOOC \'25 next month","date":"2025-01-16T00:00:00.000Z","tags":[{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"conferences","permalink":"/blog/tags/conferences"},{"inline":true,"label":"stickers","permalink":"/blog/tags/stickers"}],"readingTime":1.4,"hasTruncateMarker":true,"authors":[{"name":"Alex Sc
1heel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao at FOSDEM, State of Open Con!","description":"OpenBao will be at FOSDEM \'25 and SOOC \'25 next month","slug":"fosdem-25","authors":"cipherboy","tags":["community","conferences","stickers"],"image":"/img/bao-mascot.jpg"},"unlisted":false,"prevItem":{"title":"OpenBao Travels to FOSDEM","permalink":"/blog/bao-at-fosdem-25"},"nextItem":{"title":"December OpenBao RFC Update","permalink":"/blog/rfcs-dec-2024"}},"content":"\\n\\nI\'m happy to share that OpenBao will be present at two conferences in February: FOSDEM \'25 in Brussels and State of Open Con 2025 in London!\\n\\n\x3c!-- truncate --\x3e\\n\\n### FOSDEM\\n\\nI will be [giving a talk](https://fosdem.org/2025/schedule/event/fosdem-2025-5145-openbao-at-gitlab-building-native-secrets-for-gitlab-ci-cd-pipelines/) on Sunday, February 2nd, at 2:05 PM GMT+1 in [room UA2.118 (Henriot)](https://fosdem.org/2025/schedule/room/ua2118/) as part of the [Identity and Access Management](https://fosdem.org/2025/schedule/track/iam/) track. I\'ll give a brief history of the project, share how GitLab is using OpenBao, and ways you can become involved. Several OpenBao maintainers will be there, including Jan Martens, and stickers will be available!\\n\\nThis talk will also be [live-streamed](https://live.fosdem.org/watch/ua2118) for anyone unable to make it.\\n\\n### State of Open Con\\n\\nThanks to the generous help of [Amanda Brock](https://openuk.uk/profiles/amanda-brock/) and [Dotan Horovits](https://github.com/horovits/), OpenBao has been provided a free non-profit table at [State of Open Con](https://stateofopencon.com/) from Tuesday, February 4th to Wednesday, February 5th. If you\'re curious about OpenBao and want to try some hands-on demos, stop by the booth--plenty of stickers will be available and we\'ll be contributing an OpenBao mascot (like pictured above) to the prize drawing on Tuesday!\\n\\nIf any community members are interested in helping to staff the booth, let us know as we have one free registration remaining.\\n\\n\\n\\n### Meetings\\n\\nIf anyone is interested in meeting with me in either Brussels or London, please reach out [via email](mailto:[email protected])."},{"id":"rfcs-dec-2024","metadata":{"permalink":"/blog/rfcs-dec-2024","source":"@site/content/blog/2024-12-11-rfcs-dec-2024.md","title":"December OpenBao RFC Update","description":"Overview of in-progress OpenBao RFCs and their status","date":"2024-12-11T00:00:00.000Z","tags":[{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"mentee","permalink":"/blog/tags/mentee"},{"inline":true,"label":"rfcs","permalink":"/blog/tags/rfcs"}],"readingTime":5.47,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"December OpenBao RFC Update","description":"Overview of in-progress OpenBao RFCs and their status","slug":"rfcs-dec-2024","authors":"cipherboy","tags":["community","mentee","rfcs"]},"unlisted":false,"prevItem":{"title":"OpenBao at FOSDEM, State of Open Con!","permalink":"/blog/fosdem-25"},"nextItem":{"title":"Announcing OpenBao v2.1.0!","permalink":"/blog/release-v2-1-0"}},"content":"The second half of 2024 saw several fabulous RFCs from different contributors to OpenBao. Here\'s a few worth highlighting and how you can get involved!\\n\\n\x3c!-- truncate --\x3e\\n\\n## In-Progress\\n\\n### [openbao#697 / vault#17189 - SSH CA Multi-Issuer](https://github.com/openbao/openbao/issues/679)\\n\\n**Description**: Vault and OpenBao have [long had issues](https://github.com/hashicorp/vault/issues/17189) supporting proper rotation of CAs in both the SSH and PKI engines. Previously, an operator would either have to remount an entirely new engine, manually copying configuration and policy, or they\'d have to destructively remove the existing CA and create a new one, creating a downtime window. While PKI got updates to add multi-issuer support [in Vault v1.11](https://developer.hashicorp.com/vault/docs/release-notes/1.11.0#improved-ca-rotation), neither Vault nor OpenBao saw improvements to SSH CA rotation. This RFC by one our OpenBao Mentees, [Gabriel](https://github.com/Gabrielopesantos), brings parity by adding multi-issuer support to the SSH engine for zero-downtime CA rotation.\\n\\n**How you can help**: Gabriel is working hard on the implementation for this feature, but we\'d appreciate feedback on the design from any users of the SSH CA!\\n\\n### [openbao#753 - CEL for PKI Policy](https://github.com/openbao/openbao/issues/753)\\n\\n**Description**: The PKI Engine\'s role-based certificate validation method is inflexible: every possible certificate field and extension, complete with desired validation mechanism must be implemented in the engine itself, requiring a release for users to adopt. For instance, `allowed_domains` on a role today doesn\'t support setting default domains or rejecting requests with only a partial list of allowed domains. While functionally equivalent (in that, a user could request multiple certificates each with a subset of approved domains), it is hard for a PKI operator to ensure that all approved domains have been issued for in a single certificate. Fatima, another OpenBao Mentee, proposes to use Google\'s Common Expression Language (CEL), widely used in GCP and Kubernetes for validation and templating, to enforce issuance policy and template the final certificate from request parameters.\\n\\n**How you can help**: Have experience using CEL or doing complex, company-specific PKI integrations? We\'d love to hear from you about the proposed design!\\n\\n### [openbao#787 - Add Namespace Support](https://github.com/openbao/openbao/issues/787)\\n\\n**Description**: Vault Enterpise supports Namespaces, a way of creating multi-tenancy and delegating permissions without running multiple cluster
1s. [Users](https://lists.openssf.org/g/OpenBao-TSC/topic/openbao_dev_wg_proposal_to/108266694) [have](https://github.com/openbao/openbao/issues/486) [requested](https://github.com/orgs/openbao/discussions/293) similar abilities with OpenBao, so a temporary working group was formed to create the design and initial implementation. This RFC, published by [Peter](https://github.com/genelet/), proposes API compatibility for consuming applications but suggests many future improvements to scalability and tenant isolation.\\n\\n**How you can help**: While the initial implementation will be done by the Namespace WG, we welcome feedback on the design, testing of the feature, and designs and implementations for future enhancements.\\n\\n### [openbao#549 / vault#5275 - Recursively List Keys](https://github.com/openbao/openbao/issues/549)\\n\\n**Description**: The [most widely requested Vault feature](https://github.com/hashicorp/vault/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) with no solution [is adding the ability to recursively list keys](https://github.com/hashicorp/vault/issues/5275). Prior to [transactions](/community/rfcs/transactions/) (for consistency) and [pagination](/community/rfcs/paginated-lists/) (for resource constraining expensive calls), this was hard to do safely. This RFC proposes introducing a new operation, with HTTP verb `SCAN` or via `GET` with `?scan=true`, and ACL capability (`scan`) to allow plugin authors to introduce recursive list endpoints and operators to secure access to them.\\n\\n**How you can help**: After the initial implementation is merged, it would be great to have feedback or PRs on additional endpoints to use this new operation.\\n\\n### ACL Improvements - [openbao#769 / vault#5362 - Filter LIST Results](https://github.com/openbao/openbao/issues/769) and [openbao#791 - Enforce List Pagination](https://github.com/openbao/openbao/issues/791)\\n\\n**Description**: The [fourth-most widely requested Vault feature](https://github.com/hashicorp/vault/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc) with no solution [is filtering LIST results](https://github.com/openbao/openbao/issues/769) to only show accessible paths. [This RFC](https://github.com/openbao/openbao/issues/769) proposes a new ACL policy parameter, `list_scan_response_keys_filter_path`, which contains a path to template with each list response item (from `.keys`) to check against the ACL system for visibility under the same token policy. While this is an expensive operation, a [follow-up RFC](https://github.com/openbao/openbao/issues/791) proposes another parameter, `pagination_limit`, to allow policy authors to require usage of paginated lists (thereby reducing the load on path filtering).\\n\\n**How you can help**: It would be great to have feedback on the templating design and how support for multiple paths could potentially behave (with an `AND` or `OR` conjunctions).\\n\\n## Completed\\n\\n### [openbao#296 - Transactional Storage](https://github.com/openbao/openbao/issues/432)\\n\\n**Description**: Recently merged and released in [v2.1.0](/community/release-notes/2-1-0/) was support for transactional storage across the entire OpenBao stack (from underlying physical storage backend to plugins). This allowed us to [improve the scalability](https://github.com/openbao/openbao/issues/432) and fault-tolerance of OpenBao above and beyond what HashiCorp Vault had.\\n\\n**How you can help**: A follow-up [tracking issue](https://github.com/openbao/openbao/issues/607) invites contributions of places where transactions should be used. As always, we welcome testing of this feature.\\n\\n## Upcoming\\n\\n### [openbao#235 - Add XChaCha20-Poly1305 Barrier Encryption Support](https://github.com/openbao/openbao/issues/235)\\n\\n**Description**: OpenBao uses AES256-GCM96 as its barrier encryption algorithm. While suitably secure and FIPS compliant, this requires frequent key rotation to compensate for the 96-bit nonce (which is not collision resistant). Switching to XChaCha20-Poly1305 would allow us to maintain a smaller barrier keyring (as key rotation would not need to be done automatically) and avoid concerns over nonce collisions.\\n\\n**How you can help**: While a proof of concept was proposed, we\'re looking for a volunteer to take over polishing the feature!\\n\\n### [openbao#17 - Add ACME Support to the TLS Listener](https://github.com/openbao/openbao/issues/17)\\n\\n**Description**: While OpenBao supports PKI capabilities, due to a chicken-and-egg problem, it is hard to issue the TLS listener\'s own certificate via a CA stored in OpenBao. With auto-unseal and ACME support, however, it would be possible to do and greatly improve operator\'s experience when using other CAs as well.\\n\\n**How you can help**: While a proof of concept was proposed, much polish was needed to complete this feature and we\'re looking for a volunteer to take over development!"},{"id":"release-v2-1-0","metadata":{"permalink":"/blog/release-v2-1-0","source":"@site/content/blog/2024-11-29-release-v2-1-0.mdx","title":"Announcing OpenBao v2.1.0!","description":"We are thrilled to announce the availability of OpenBao v2.1.0, focused on safety and scalability improvements!","date":"2024-11-29T00:00:00.000Z","tags":[{"inline":true,"label":"release","permalink":"/blog/tags/release"},{"inline":true,"label":"announcement","permalink":"/blog/tags/announcement"},{"inline":true,"label":"release","permalink":"/blog/tags/release"}],"readingTime":3.73,"hasTruncateMarker":true,"authors":[{"name":"Alex Sc
1heel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Announcing OpenBao v2.1.0!","description":"We are thrilled to announce the availability of OpenBao v2.1.0, focused on safety and scalability improvements!","slug":"release-v2-1-0","authors":"cipherboy","tags":["release","announcement","release"]},"unlisted":false,"prevItem":{"title":"December OpenBao RFC Update","permalink":"/blog/rfcs-dec-2024"},"nextItem":{"title":"Implementing Transactions in Raft","permalink":"/blog/raft-transactions"}},"content":"import Head from \'@docusaurus/Head\';\\n\\n<Head>\\n <link rel=\\"canonical\\" href=\\"https://lfedge.org/announcing-openbao-v2-1-0-transactional-storage-postgresql-and-more/\\" />\\n</Head>\\n\\n\\n\\n\\nWe are thrilled to announce [the availability](/downloads/?version=v2.1.0) of [OpenBao v2.1.0](/community/release-notes/2-1-0/), focused on safety and scalability improvements!\\n\\nThis release spent some time laying the groundwork for safety and scalability improvements for releases to come. With the help of the community, OpenBao will now take advantage of transactional storage semantics from its underlying data store, giving operators and plugin developers confidence in the consistency of storage writes. This storage safety allows us to focus on alternative storage layouts for improving scalability, for instance, increasing the maximum number of mount table entries past the single-entry limit.\\n\\nThis release also features contributions from many new and repeat contributors; thank you all!\\n\\n\x3c!-- truncate --\x3e\\n\\n## Key highlights of the release\\n\\nMajor features:\\n\\n - **Remove Mount Table Limits**: Using transactional storage, we\'ve split the auth and secret mount tables into separate storage entries, removing the requirement that the entire table fit into a single storage entry limited by max_entry_size. This allows potentially hundreds of thousands of mounts on a single scaled-up server.\\n - **Transactional Storage**: Plugin developers can now take advantage of safe storage modification APIs when the underlying physical storage supports them. The physical.TransactionalBackend and logical.TransactionalStorage types allow developers to begin read-only and writable transactions, committing or rolling back the desired changes.\\n - **Transit**: Support PKI CSR and certificate storage alongside key material. This allows callers to securely create keys and submit requests for certificates without the key material leaving Transit. Storage of the certificate on the key avoids the need for an additional K/V mount. Rotation of this certificate and its chain is also supported.\\n - `physical/postgres`: Reintroduce Postgres database for OpenBao storage, implementing paginated list support. This feature is currently in **preview** and breaking changes may occur.\\n\\nPlugin improvements:\\n\\n - `auth/jwt`: Allow templating ACL policies from data in claims on JWT or OIDC ID tokens.\\n - `auth/oidc`: Add a new oauth2_metadata configuration option to enable sending any of the tokens from the token issuer to the client.\\n - `auth/oidc`: Add a new callback_mode role option value **device** to use the oidc device flow instead of a callback, add a new poll_interval role option to control how often to poll for a response, and add a new callbackmode=device option to the oidc login method in the cli.\\n - `auth/oidc`: Add new **callback_mode=direct** role option to cause the oidc callback to be direct to the server instead of the client, and add a callbackmode=direct option to the oidc login method in the cli.\\n - `docker`: add /bin/vault symlink to docker images.\\n - `rpm`: Fix packaging to properly annotate configs entries for noreplace.\\n - `secrets/kv`: Implement transactions to prevent canceled operations from corrupting storage.\\n
1- `secrets/pki`: Use transactions for root generation, issuer import.\\n - `secrets/pki`: add not_before parameter to precisely define a certificate\'s \\"not before\\" field.\\n - `secrets/pki`: Add revoked_safety_buffer to control retention on revoked certificates separately from expired certificates.\\n - `secrets/pki`: Delete invalid certificates during tidy via tidy_invalid_certs=true if they cannot be parsed due to Go\'s x509 handling.\\n - `secrets/pki`: Support revoking expired certificates with the allow_expired_cert_revocation CRL configuration.\\n - `storage/postgresql`: Allow table creation to improve first-start UX.\\n\\nStay tuned for more great features to come!\\n\\n## Looking ahead\\n\\nSeveral feature-related working groups have spun up, including one around Namespaces which will bring welcomed multi-tenancy improvements in the future. OpenBao\'s mentees have also been making great improvements! Stay tuned for progress on [multi-issuer SSH CA support](https://github.com/openbao/openbao/issues/679) and [Common Expression Language (CEL)-based PKI issuance policy](https://github.com/openbao/openbao/issues/753).\\n\\nChanges are well underway for the next release, including usability enhancements to the PKI engine, improvements to the K/V engine based on paginated lists and transactional storage, additions to the ACL system to handle recursive listing, and an RFC for restricting the results of [list operations to only visible entries](https://github.com/openbao/openbao/issues/769).\\n\\nIf anyone has private forks of HashiCorp Vault, we are happy to collaborate around timely security fixes or syncing modifications to the core or plugins.\\n\\nAs always, we appreciate any and all contributions!\\n\\n---\\n\\nThis blog post was originally posted on the [LF Edge Blog](https://lfedge.org/announcing-openbao-v2-1-0-transactional-storage-postgresql-and-more/)."},{"id":"raft-transactions","metadata":{"permalink":"/blog/raft-transactions","source":"@site/content/blog/2024-10-27-transaction-details.md","title":"Implementing Transactions in Raft","description":"Analysis of OpenBao\'s Raft storage backend and implementing transactions in it.","date":"2024-10-27T00:00:00.000Z","tags":[{"inline":true,"label":"technical","permalink":"/blog/tags/technical"},{"inline":true,"label":"raft","permalink":"/blog/tags/raft"},{"inline":true,"label":"core","permalink":"/blog/tags/core"}],"readingTime":6.55,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Implementing Transactions in Raft","description":"Analysis of OpenBao\'s Raft storage backend and implementing transactions in it.","slug":"raft-transactions","authors":"cipherboy","tags":["technical","raft","core"],"image":"https://raw.githubusercontent.com/openbao/artwork/refs/heads/main/color/openbao-text-color.svg"},"unlisted":false,"prevItem":{"title":"Announcing OpenBao v2.1.0!","permalink":"/blog/release-v2-1-0"},"nextItem":{"title":"My First Week as an OpenBao Mentee!","permalink":"/blog/my-first-week-openbao-mentee"}},"content":"## Overview\\n\\nOpenBao, like its upstream, favors the [`raft` internal storage engine](/docs/configuration/storage/raft).\\nWhile more complex than relying on a database for replication, this storage\\nengine allows us to have lower latency on read operations, because it uses\\na [local K/V implementation](https://github.com/etcd/bbolt) based on [B+-trees](https://en.wikipedia.org/wiki/B%2B_tree). For workloads\\nwith low writes but high reads (typical of most uses of K/V secrets), this\\ntrade off allows for the best performance.\\n\\nAn earlier [blog post](/blog/transactions) talked about the availability of\\ntransactions in the [`main` branch](https://github.com/openbao/openbao/tree/main), this post will focus on\\nthe technical details of implementing transactions.\\n\\n\x3c!-- truncate --\x3e\\n\\n[Raft][raft-algo] is consensus protocol typically used in [databases][etcd]\\nand other distributed systems. Nodes in the algorithm are given voting\\nprivileges, allowing them to select a single leader node and replace it if\\nit becomes unresponsive. This gives the Raft protocol availability. Only the\\nleader node is allowed to perform commands, which are writes in the case of\\nOpenBao. For a write to be applied, every node must acknowledge it, giving the\\nRaft protocol consistency. By running an odd number of nodes, we ensure a\\nunique election result in the case of disagreements.\\n\\nIn OpenBao, the [`raft` storage backend][raft-backend] is the combination of\\nan implementation of the [HashiCorp Raft library][hcp-raft] and the\\n[bbolt](https://github.com/etcd/bbolt) K/V store. When Raft applies a [WAL][]\\nentry, the underlying [FSM][raft-fsm] applies the corresponding operations.\\nPrior to transactions, these consisted of bare [Put and Delete\\nops][storage-write]. Further, read requests were [handled\\nindividually][storage-read], meaning there was no consistency between two\\nseparate requests.\\n\\n## Implementing transactions\\n\\nIn [introducing transactions][transaction-rfc], we thus needed an interface\\nwhich let us attach persistent state, such as an underlying [bbolt\\ntransaction][bbolt-txn
1]. Notably, bbolt [only supports][bbolt-txn-limits] a\\nsingle non-exclusive write transaction and parallel read transactions.\\nFurthermore, opening a write transaction when the user wants a writable\\nstorage isn\'t ideal as we need to ensure the values written to Raft are\\ncorrectly applied: we\'d thus need to hold the write transaction even longer,\\nuntil Raft has finished applying, to be able to commit the underlying write\\ntransaction. This blocks all other writes which may be occurring, such as\\nearlier Raft log entries.\\n\\nThus, we needed a hybrid design: use read transactions for consistency,\\nregardless of the transaction writeability, but send a complex operation\\nentry to Raft which allowed verifying that all operations which occurred\\nhad not been impacted by any other in-flight operations.The Raft\\nimplementation in OpenBao already supported complex operations and allowed\\nus to indicate a return value on individual operations. This let us safely\\nconflict a transaction by returning an error message to the requester, rather\\nthan erring at the Raft FSM level, which would cause a panic and subsequent\\nleader election. In the case of our Raft implementation, transactions are\\nnon-blocking to avoid potential implicit locking and thus subtle lock ordering\\nbugs and thus we\'d prefer to have the caller retry the operation entirely if\\nit conflicted.\\n\\nThis gives us the equivalent of write committed transactions from standard\\nrelational databases.\\n\\nOur structured [transaction operation][txn-commit] thus looks like:\\n\\n```\\n[\\n { beginTxnOp }\\n { ... verifyReadOp ... }\\n { ... verifyListOp ... }\\n { ... perform all writes ... }\\n { commitTxnOp }\\n]\\n```\\n\\nHere, for any write (a `Put(...)` or `Delete(...)`) or a `Get(...)`, we issue\\na corresponding read on the underlying storage transaction. Into the log\\nentry, we save a message indicating both the read entry and the [hash of its\\nvalue][hash-value]. Similarly for `List(...)` operations, we also save the\\nunderlying storage entries, but [include one additional entry][list-impl] past\\nthe end of our results to ensure that we did not artificially exclude any\\nentries.\\n\\nDoing this complicates our transaction\'s implementation: each write operation\\nmust be cached so that future `List(...)` or `Get(...)` operations within the\\ntransaction can be adjusted to return a consistent value. For `ListPage(...)`\\nin particular, this is made more complex by needing to efficiently synthesize\\nthree data sources: the entries in the underlying bbolt transaction, any newly\\nwritten entries, and any deleted entries.\\n\\nHowever, this additional bookkeeping work and using the underlying transaction\\nallows us to commit a minimal transaction: no unnecessary verified reads or\\nduplicate writes are sent via Raft.\\n\\nOn the other side, when the log is confirmed, [application][txn-apply] first\\nverifies that the current storage state matches the verified expectations and\\nrefuses to perform any writes if it differs, returning a transaction commit\\nfailure to the requester. This lets us avoid unnecessarily applying any write\\noperations: all logs within the batch are committed to bbolt using a single\\n[large transaction][batch-apply-txn] for performance and correctness w.r.t.\\nthe expectations of the Raft protocol.\\n\\n## Potential optimization as future work\\n\\nWhen discussing my plans for implementing transactions with a colleague at\\nGitLab, Sami Hiltunen, he pointed out an optimization: by keeping track of\\nthe current index at the beginning of the logical transaction, we could skip\\nverifications for which no subsequent log entry impacted. This lets us do\\nfewer duplicate read operations at the expense of some additional bookkeeping,\\nto track entries newer than the oldest transaction and which paths they\\nmodified in storage.\\n\\nHowever, while this speeds up the batch application\'s view, it doesn\'t help us\\navoid unnecessarily committing the verifications to the log itself, as we do\\nthis verification within the batch application. Better, though significantly\\nmore work, would be to do a pre-application sanity check, allowing us to drop\\nunnecessary verification operations from our commit if we could tell at\\n[request time][raft-apply-log] that further verification was unnecessary.\\n\\nThis is left as a future improvement.\\n\\nAdditionally, we are currently sub-optimally using [caches][physical-cache]\\nin transactions. Because we do not have a transaction-aware cache library,\\nwe currently create a new, empty cache per transaction and do not repopulate\\nthe global cache on successful commit to the underlying storage. This limits\\nour performance on high-latency storage backends which support transactions.\\nHowever, fixing this likely requires expensive locking: all write, transaction\\ncreation and commit events likely require an exclusive lock to ensure\\nconsistency of the cache. A more transaction aware cache implementation would\\nalso be benef
1icial, so that we are not duplicating the entire cache at\\ntransaction creation time; perhaps the existing [memdb library][memdb] could\\nbe used for this.\\n\\nThis is also left as a future improvement.\\n\\n:::info\\nWe\'d love feedback and testing on the transactional storage implementation!\\n\\nBuild OpenBao from the `main` branch and submit any bug reports or\\nperformance discrepancies via [GitHub issue][file-issue].\\n:::\\n\\n[raft-algo]: https://raft.github.io/\\n[etcd]: https://etcd.io/\\n[WAL]: https://en.wikipedia.org/wiki/Write-ahead_logging\\n[raft-backend]: https://github.com/openbao/openbao/tree/main/physical/raft\\n[hcp-raft]: https://github.com/hashicorp/raft\\n[raft-fsm]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/physical/raft/fsm.go\\n[storage-write]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/physical/raft/raft.go#L1523-L1553\\n[storage-read]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/physical/raft/raft.go#L1493-L1521\\n[transaction-rfc]: /community/rfcs/transactions/\\n[bbolt-txn]: https://pkg.go.dev/go.etcd.io/bbolt#Tx\\n[bbolt-txn-limits]: https://pkg.go.dev/go.etcd.io/bbolt#pkg-overview\\n[txn-commit]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/physical/raft/transaction.go#L610-L722\\n[hash-value]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/physical/raft/transaction.go#L97-L115\\n[list-impl]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/physical/raft/transaction.go#L479-L485\\n[txn-apply]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/physical/raft/fsm.go#L678-L758\\n[batch-apply-txn]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/physical/raft/fsm.go#L824-L838\\n[raft-apply-log]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/physical/raft/raft.go#L1598-L1689\\n[physical-cache]: https://github.com/openbao/openbao/blob/c9201295ed833b431249f4592f32b1946b69f263/sdk/physical/cache.go\\n[memdb]: https://pkg.go.dev/github.com/hashicorp/go-memdb\\n[file-issue]: https://github.com/openbao/openbao/issues/new?assignees=&labels=bug%2Cpending-decision&projects=&template=bug_report.md&title="},{"id":"my-first-week-openbao-mentee","metadata":{"permalink":"/blog/my-first-week-openbao-mentee","source":"@site/content/blog/2024-10-24-mentees-first-week.md","title":"My First Week as an OpenBao Mentee!","description":"Sharing my first experiences as an OpenBao mentee.","date":"2024-10-24T00:00:00.000Z","tags":[{"inline":true,"label":"mentee","permalink":"/blog/tags/mentee"}],"readingTime":2.45,"hasTruncateMarker":true,"authors":[{"name":"Fatima Patel","url":"https://fatties-portfolio.vercel.app","socials":{"github":"https://github.com/fatima2003","linkedin":"https://www.linkedin.com/in/fatima-p-201b50198/"},"key":"FattiesPatties","page":null}],"frontMatter":{"title":"My First Week as an OpenBao Mentee!","description":"Sharing my first experiences as an OpenBao mentee.","slug":"my-first-week-openbao-mentee","authors":"FattiesPatties","tags":["mentee"]},"unlisted":false,"prevItem":{"title":"Implementing Transactions in Raft","permalink":"/blog/raft-transactions"},"nextItem":{"title":"Overview on Transactional Storage","permalink":"/blog/transactions"}},"content":"\\n\\n## My Journey Begins\\nHey everyone! I\u2019m Fatima and I\u2019m excited to share how my OpenBao journey started! I had been working on app development but was eager to break into the cybersecurity world. So I browsed through various open-source projects and stumbled upon OpenBao. The project\u2019s purpose caught my interest and, of course, the little bao mascot sealed the deal so I decided to dive in and set it up.\\n\\nWhile running OpenBao tests on my Mac, I ran into a minor compatibility error. Instead of getting frustrated, I saw it as an opportunity to contribute. I submitted my first issue to the OpenBao repository, worked on a fix, and a few days later, my pull request (PR) was approved! The excitement of having my first merged PR got me motivated to try out another issue, which also got merged later! After lurking around the repo for a few days, my mentor, Alex reached out to me with this wonderful opportunity and that is how my OpenBao journey began! \\n\\n\x3c!-- truncate --\x3e\\n\\n## My First Week as a Mentee\\n\\nMy mentor and I discu
1ssed a few project ideas and issues I could pick up via mail, namely, implementing PQC (Post Quantum Cryptography) into OpenBao, ACME TLS listeners, improvements to the PKI (Public Key Infrastructure) role system, a role system for intermediate CAs and a few others.\\n\\nI started off my week by picking a good first issue, [#459](https://github.com/openbao/openbao/issues/459), which focuses on allowing revocation of expired certificates. To get a clear understanding of it, I dove into the documentation, explored related issues, and familiarized myself with the underlying use cases. Once I had a solid grasp of the problem, I started exploring the codebase, running tests, and reviewing field validation rules along with the CRL configuration.\\n\\nThe week ended with a call with my mentor, where I shared updates on the tasks I had completed, asked a few questions, and proposed the next issue I\'d like to work on. Alex was incredibly helpful, guiding me through my queries and offering valuable insights. Overall, my first week went by pretty smoothly despite the usual jitters that come with starting something new.\\n\\n## What\u2019s Next?\\nMy excitement to contribute to OpenBao only grows as I dive deeper into the project. I am still relatively new to Go, how PKI is used in industry and the repository, so my short term goal is to be able to understand the project by picking smaller issues and then eventually work my way to bigger features. I\u2019m currently working on issues within the PKI system, with plans to enhance it further. There\u2019s also potential to explore ACME TLS listeners or even delve into Post Quantum Cryptography down the line!\\n\\nI am documenting my OpenBao journey via [project journals](https://github.com/fatima2003/OpenBao-Project-Journals/tree/main) which you can follow along to see my progress as a mentee!"},{"id":"transactions","metadata":{"permalink":"/blog/transactions","source":"@site/content/blog/2024-10-16-transactions.md","title":"Overview on Transactional Storage","description":"A high-level overview on OpenBao\'s support for transactional storage.","date":"2024-10-16T00:00:00.000Z","tags":[{"inline":true,"label":"technical","permalink":"/blog/tags/technical"},{"inline":true,"label":"storage","permalink":"/blog/tags/storage"},{"inline":true,"label":"core","permalink":"/blog/tags/core"}],"readingTime":2.73,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Overview on Transactional Storage","description":"A high-level overview on OpenBao\'s support for transactional storage.","slug":"transactions","authors":"cipherboy","tags":["technical","storage","core"],"image":"https://raw.githubusercontent.com/openbao/artwork/refs/heads/main/color/openbao-text-color.svg"},"unlisted":false,"prevItem":{"title":"My First Week as an OpenBao Mentee!","permalink":"/blog/my-first-week-openbao-mentee"},"nextItem":{"title":"OpenBao\'s First Roadmap and Community Direction","permalink":"/blog/roadmap"}},"content":"Recently we merged the last of the [transactional storage](/community/rfcs/transactions/) [pull requests](https://github.com/openbao/openbao/pull/262), including [PostgreSQL support](https://github.com/openbao/openbao/pull/608)!\\n\\n\x3c!-- truncate --\x3e\\n\\nPreviously, upstream\'s storage model was built on [four basic operations](https://github.com/openbao/openbao/blob/2cb5d444b26cfdc79d814f9696c7f68f9c43606f/sdk/logical/storage.go#L31-L38): `Get(...)`, `Put(...)`, `List(...)`, and `Delete(...)`. Ahead of [OpenBao\'s initial v2.0.0 GA release](/community/release-notes/2-0-0/), we added support for a fifth operation, [paginated list\'s](/community/rfcs/paginated-lists/) `ListPage(...)`. Each of these operations were individually atomic, in that they either succeeded or erred with no change for a partial change.\\n\\nHowever, there were no consistency guarantees across storage operations: two parallel requests coming into the same plugin could result in silently conflicting storage operations. For example, [in the PKI engine](/docs/secrets/pki/), fetching the default issuer (certificate authority) required at least the following reads:\\n\\n - [`/config/issuers`](https://github.com/openbao/openbao/blob/2cb5d444b26cfdc79d814f9696c7f68f9c43606f/builtin/logical/pki/storage.go#L1099-L1114) to resolve the value of `default`, and\\n - [`/config/issuer/:id`](https://github.com/openbao/openbao/blob/2cb5d444b26cfdc79d814f9696c7f68f9c43606f/builtin/logical/pki/storage.go#L658-L678) to read the actual default issuer.\\n\\nThis meant that, if a second request came in deleting the issuer prior to the first request (say, to issue a leaf certificate) read the second entry, the first request would fail due to storage inconsistency. Or, [in the KVv2 engine](https://github.com/openbao/openbao/issues/482), a canceled delete request could result in broken entries.\\n\\nTransactions fix this and allow a plugin to have a consistent view of storage and ensure that any write operations are appropriately conflicted or locked and fail safely even in the event of request cancelation or other failure modes.\\n\\nTransactions also let us make several incremental design improvements: previously only single entr
1ies had consistency guarantees so the mount table had to fit within a single storage entry. Now, we can [split the mount table](https://github.com/openbao/openbao/issues/432) into separate entries and use transactions to have durable, safe modifications to these entries.\\n\\nImplementing transactions had several design challenges: The HashiCorp Raft implementation had no native support for transactions, so we needed to figure out how to reconcile this with the underlying operation log. We opted to put all commits (with write operations) on the log, regardless of if they\'d conflict, allowing all nodes to verify the consistency of the transaction. Further, PostgreSQL\'s internal locking [means that two transactions cannot be executed from the same thread](https://stackoverflow.com/questions/32255557/postgresql-hang-forever-on-serializable-transaction). This forced us to loosen up some of our transaction semantic testing, to ensure we remain compatible with both implementations. If you\'re interested in the exact details [be sure to check out the RFC](/community/rfcs/transactions/).\\n\\nMost importantly, we\'re excited about the possibilities that safer, more durable storage semantics bring!\\n\\n:::info\\nThe work is not yet done!\\n\\nIf you\'re interested in helping out, take a look at our [follow-up issue](https://github.com/openbao/openbao/issues/607): we\'ll need the community\'s help to ensure plugins and core safely use transactions for all relevant operations. We\'d also appreciate feedback from anyone willing to run test workloads against the main branch to ensure the stability of both the Raft and PostgreSQL storage backends!\\n:::"},{"id":"roadmap","metadata":{"permalink":"/blog/roadmap","source":"@site/content/blog/2024-10-11-roadmap.md","title":"OpenBao\'s First Roadmap and Community Direction","description":"An explanation of OpenBao\'s proposed roadmap and direction for the community.","date":"2024-10-11T00:00:00.000Z","tags":[{"inline":true,"label":"direction","permalink":"/blog/tags/direction"},{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"collaboration","permalink":"/blog/tags/collaboration"}],"readingTime":1.84,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"OpenBao\'s First Roadmap and Community Direction","description":"An explanation of OpenBao\'s proposed roadmap and direction for the community.","slug":"roadmap","authors":"cipherboy","tags":["direction","community","collaboration"],"image":"https://raw.githubusercontent.com/openbao/artwork/refs/heads/main/color/openbao-vertical-text-color.svg"},"unlisted":false,"prevItem":{"title":"Overview on Transactional Storage","permalink":"/blog/transactions"},"nextItem":{"title":"Maintainers, Committers, and Moderators Oh-My!","permalink":"/blog/maintainers"}},"content":"I\'m pleased to announce that our first [direction and roadmap document](https://github.com/openbao/openbao/issues/569) has been approved by the TSC!\\n\\nThis represents a major commitment to openness for this project. Historically, upstream hasn\'t published an open roadmap or collaborated with the community on a shared vision and direction for their project. \x3c!-- truncate --\x3e As part of this fork, we wanted to take the time to address some long-standing community-requested issues and make sure we intentionally collaborate with our users and contributors, regardless of employer, contribution status, or any monetary payment or contract.\\n\\n_Aside_: Sure, this roadmap may not be perfect. It doesn\'t have timelines for one! It may not reflect everything that anyone has ever dreamed of for this project. But it prioritizes some key issues where we feel that we can make some immediate progress and lead the project in key, focused directions.\\n\\nWe\'ve categorize the roadmap into three main areas:\\n\\n 1. \\"**Safer**\\": to enable safer operation of OpenBao, through transactions, break-glass procedures, and improved ACL and audit capabilities,\\n 2. \\"**Community**\\": to encourage community maintainership of external plugins and client libraries, and\\n 3. \\"**Scalability**\\": to improve scalability of the core, through reducing resource consumption and removing design limitations.\\n\\nEach of these areas are places were the community has _wanted more_ from OpenBao and its upstream and where we think we can deliver.\\n\\nI\'ll save the details for the [roadmap tracking issue](https://github.com/openbao/openbao/issues/569), but some highlights are:\\n\\n1. Finishing transactional storage and using it improve scalability, such as by expanding the mount table limits.\\n2. Parallel seal mechanisms and HSM/PKCS#11 auto-unseal capabilities.\\n3. Reviving the PostgreSQL storage backend and bringing transactional storage to it.\\n4. Namespace support for true multi-tenancy.\\n5. Reviving and refreshing the UI.\\n6. Building a first-class plugin ecosystem, through community-maintained plugins and a registry for efficient use.\\n7. ...and many more!\\n\\
1n:::info\\nInterested in some of these features? We need your help!\\n\\nReact (:+1:) to issues on GitHub to show your support, help contribute use cases or design documents, or submit code implementing these features! If you need help getting started, [just reach out](https://github.com/openbao/#contact)!\\n:::"},{"id":"maintainers","metadata":{"permalink":"/blog/maintainers","source":"@site/content/blog/2024-10-03-maintainers.md","title":"Maintainers, Committers, and Moderators Oh-My!","description":"OpenBao\'s Community Roles policy is an important step towards open governance.","date":"2024-10-03T00:00:00.000Z","tags":[{"inline":true,"label":"community","permalink":"/blog/tags/community"},{"inline":true,"label":"policies","permalink":"/blog/tags/policies"},{"inline":true,"label":"governance","permalink":"/blog/tags/governance"}],"readingTime":2.88,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Maintainers, Committers, and Moderators Oh-My!","description":"OpenBao\'s Community Roles policy is an important step towards open governance.","slug":"maintainers","authors":"cipherboy","tags":["community","policies","governance"],"image":"https://raw.githubusercontent.com/openbao/artwork/refs/heads/main/color/openbao-vertical-text-color.svg"},"unlisted":false,"prevItem":{"title":"OpenBao\'s First Roadmap and Community Direction","permalink":"/blog/roadmap"},"nextItem":{"title":"Profiles for Cross-Plugin Communication","permalink":"/blog/profiles"}},"content":"\\\\o Hello OpenBao community!\\n\\nIn our last [community post](/blog/kickoff/), we said:\\n\\n> **Join the community and its leadership today.**\\n\\nBut you said: _it is not clear how!_\\n\\nGood news: Our community roles are [approved and live](https://github.com/openbao/openbao/blob/main/MAINTAINERS.md#openbao-community-roles)!\\n\\n\x3c!-- truncate --\x3e\\n\\n## How were the community roles created?\\n\\nOpen discussions on what roles should exist in the community started [early in the community\'s history](https://github.com/orgs/openbao/discussions/228). Eventually, I put forward [a proposal](https://lists.openssf.org/g/openbao/topic/proposal_community/108163995) for review [by the community](https://lf-edge.atlassian.net/wiki/spaces/OP/pages/15211863/OpenBao+Meetings) (on August 29th, 2024) and with the support of the [TSC](https://lf-edge.atlassian.net/wiki/spaces/OP/pages/15212291/2024-08-08+OpenBao+TSC+Meeting). This was adopted officially on September 30th, 2024 thanks to unanimous votes [by the TSC](https://lists.openssf.org/g/OpenBao-TSC/topic/announce_roadmap/108738128)!\\n\\n## What are our community roles?\\n\\nThe accepted proposal [introduced three roles](https://github.com/openbao/openbao/blob/main/MAINTAINERS.md#overview), open for anyone, regardless of employer, to apply:\\n\\n1. Org-wide [**Moderators**](https://github.com/openbao/openbao/blob/main/MAINTAINERS.md#organization-level-moderators-1), to help triage issues and pull requests across all of our repositories.\\n2. Repository [**Committers**](https://github.com/openbao/openbao/blob/main/MAINTAINERS.md#repository-level-committers), to help maintain specific plugins, libraries, or portions of the core.\\n3. Org-wide [**Maintainers**](https://github.com/openbao/openbao/blob/main/MAINTAINERS.md#organization-level-maintainers-1), which are given broader permissions across all repositories and are automatically voting members of the Dev WG.\\n\\nThese roles have _increasing barriers to entry_: being a security-sensitive project, we need to balance our desire for open governance with an adequate vetting process for contributing.\\n\\n## How do I apply?\\n\\nWhen eligibility requirements are met, application is usually as simple as collecting some evidence and accomplishments in the community and sending an email to [the mailing list](https://lists.openssf.org/g/openbao)! Then a relevant body of contributors will vote on applicants.\\n\\n## Why is this important?\\n\\nA project defining its own governance is an important step along the [project maturity process](https://lf-edge.atlassian.net/wiki/spaces/LE/pages/15848760/Project+Stages+Definitions+and+Expectations).\\n\\nBut more than that, OpenBao is an open-source project under open-governance. Unlike HashiCorp\'s [Core Contributors](https://www.credly.com/org/hashicorp/badge/hashicorp-core-contributor-2024) _award_, these positions can give community members _maintainer_ access to OpenBao repositories, something HashiCorp never allowed non-employees to have. Achieving organization-level maintainer allows you a vote on the Development Working Group and passing a vote by the TSC is a testament to the impact of your work. It gives you, the contributor, a voice in this project\'s leadership. And increasing the diversity and preventing a monoculture by a single employer is what will help make this experiment succeed.\\n\\n## What\'s next for OpenBao?\\n\\nGlad you asked! Next up is ratifying the [Development Working Group charter](https://gist.github.com/cipherboy/f6fc1f970f9c5feb753e2dd58e145eff) and defining how one [joins the TSC](https://lf-edge.atlassian.net/wiki/spaces/OP/pages/62586881/2024-10-10+OpenBao+TSC+Meeting). These two documents are the last key pieces of governance our community needs to define as it works towards stage 2 in the LF Edge project maturity model.\\n\\n:::info\\nInterested in joining to help maintain OpenBao going forward? Apply today!\\n\\nWe\'re especially looking for candidates who are interested in helping to own specific plugins (including GCP and AWS) and Kubernetes support!\\n:::"},{"id":"profiles","metadata":{"permalink":"/blog/profiles","source":"@site/content/blog/2024-09-27-profiles.md","title":"Profiles for Cross-Plugin Communication","description":"A server-side request framework might alleviate some need for a new ACL system.","date":"2024-09-27T00:00:00.000Z","tags":[{"inline":true,"label":"technical","permalink":"/blog/tags/technical"},{"inline":true,"label":"plugins","permalink":"/blog/tags/plugins"},{"inline":true,"label":"core","permalink":"/blog/tags/core"}],"readingTime":4.12,"hasTruncateMarker":true,"authors":[{"name":"Alex Sc
1heel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Profiles for Cross-Plugin Communication","description":"A server-side request framework might alleviate some need for a new ACL system.","slug":"profiles","authors":"cipherboy","tags":["technical","plugins","core"],"image":"/img/how-openbao-works.png"},"unlisted":false,"prevItem":{"title":"Maintainers, Committers, and Moderators Oh-My!","permalink":"/blog/maintainers"},"nextItem":{"title":"Announcing the OpenBao Blog!","permalink":"/blog/kickoff"}},"content":"OpenBao and upstream [lack server-side cross-plugin communication](https://github.com/hashicorp/vault/issues/21023#issuecomment-1579232437).\\n\\nAs recently seen with an [OIDC feature](https://github.com/openbao/openbao/pull/320), this shortcoming often needs to be worked around on the client side, potentially exposing sensitive information.\\n\\nThere\'s usually two paths discussed for cross-plugin communication:\\n\\n1. Requests bound under the context of the original user token.\\n2. Designing some other authorization system or an internal API based design.\\n\\n\x3c!-- truncate --\x3e\\n\\nBoth have some trade-offs: the security model of the first makes more intuitive sense to reason about the complexity of its implementation. There\'s no additional design necessary for restricting access to other plugins. However, it has some undesirable side-effects: it prevents a trusted (server-bound) channel between two plugins. As we later decided to revisit the OIDC changes, we opted to allow auth plugins to write to an [internal data field](https://github.com/openbao/openbao/issues/519) that becomes accessible on the entity. This prevented the need for the client (
1an partially trusted party) from needing to hold the sensitive OIDC tokens but allowed any plugin to be able to access its value. However, plugins would still need to be updated to read this field; thus it has limited utility.\\n\\nWhile the need for a trusted channel still exists, I\'d like to talk about a more flexible idea for improving the developer experience of OpenBao, that could potentially address ACL-bound requests. A **profile system**.\\n\\nOne of the major learnings of [ACME](https://datatracker.ietf.org/doc/html/rfc8555) is that simplicity of automation and integration greatly improve the developer experience of a protocol. OpenBao, from a developer\'s perspective, is rather hard to understand: there\'s all sorts of auth and secrets engines that one can use and it is down to an organization\'s policies and technical decisions which ones they\'ll use. Unless they\'re interacting with a KMS, however, many applications\' usage of secrets is transactional: single requests to many engines to collect all the secrets they need to operate.\\n\\nLet\'s introduce an **application profile**: a way for operators to define a single endpoint which collects a series of requests into a single place on behalf of a caller. Perhaps this includes four major components: `input` from the request, an optional `auth` step (to transparently handle authentication on behalf of the caller), one or more `request` blocks to collect the necessary secrets, and a `output` block to format the response.\\n\\nThis looks a lot like the ACL policy system with some extra directives:\\n\\n```hcl\\ninput {\\n authenticated = true\\n data = {\\n \\"common_name\\": \\"string\\"\\n }\\n}\\n\\nrequest \\"cert\\" {\\n path = \\"/v1/pki/issue/example\\"\\n operation = \\"read\\"\\n err = fatal\\n data = {\\n \\"common_name\\": input.data.common_name\\n }\\n}\\n\\nrequest \\"dbpass\\" {\\n path = \\"/v1/database/creds/example\\"\\n operation = \\"read\\"\\n err = fatal\\n}\\n\\noutput {\\n data = {\\n \\"listener\\": {\\n \\"certificate\\": request.cert.data.certificate,\\n \\"private_key\\": request.cert.data.private_key,\\n \\"issuer\\": request.cert.data.issuing_ca\\n },\\n \\"database\\": {\\n \\"username\\": request.dbpass.data.username,\\n \\"password\\": request.dbpass.data.password\\n },\\n \\"leases\\": [\\n request.cert.lease_id,\\n request.dbpass.lease_id\\n ]\\n }\\n}\\n```\\n\\nImportantly, each step in this example is authenticated using the required input token, which must have access to all requested resources (`/v1/pki/issue/example` and `/v1/database/creds/example`) but also the ability to execute this profile as well (perhaps via `/v1/sys/profiles/execute/:name`). Administrators could modify profiles (perhaps via `/v1/sys/profiles/modify/:name`) and pre-configure them for applications. With [namespaces](https://github.com/openbao/openbao/issues/486), this could help the organization of profiles, limiting the profile to paths under the given namespace.\\n\\nWe could perhaps get something more similar to ACME, with JWT-based authentication and a signature over the input fields (potentially including a server controlled and validated nonce as well). In this way, unless the profile author specifies it, the requester would not see the underlying token at all, though obviously would be able to acquire one directly from the JWT auth method with their token.\\n\\nAdditionally, a capability such as `direct-deny` could be added to the ACL system, allowing an operator to deny direct usage of OpenBao (while allowing the profile system to continue to operate). This would be in contract to the existing `deny` which would continue to deny all usage.\\n\\nEither with more complex [templating](https://pkg.go.dev/text/template) instructions than the profile system or by creative block names, we could support operations such as chaining queries from the result of `LIST` operations (thus manually building `ListWithInfo` responses) or iterated queries. With cross-request transactions, we could prohibit certain write calls from succeeding if all requests in the profile do not succeed. Or, maybe this language just ends up looking like [OpenTofu](https://
1opentofu.org/docs/v1.6/language/expressions/for/)...\\n\\nRegardless, there are a lot of ideas left to explore before this feature becomes a reality.\\n\\n:::info\\n\\nA profile system is an important step in helping to make OpenBao more usable and approachable to application developers. And if standardized, it encourages broader compatibility across the entire secrets management landscape -- beyond OpenBao and HashiCorp Vault.\\n\\nHave requirements for the new profile system or interested in helping to design and implement it? Let us know!\\n\\n:::"},{"id":"kickoff","metadata":{"permalink":"/blog/kickoff","source":"@site/content/blog/2024-09-23-kickoff.md","title":"Announcing the OpenBao Blog!","description":"OpenBao Blog Kickoff - Focused on the Community and Technical Challenges","date":"2024-09-23T00:00:00.000Z","tags":[{"inline":true,"label":"intro","permalink":"/blog/tags/intro"},{"inline":true,"label":"trends","permalink":"/blog/tags/trends"},{"inline":true,"label":"community","permalink":"/blog/tags/community"}],"readingTime":1.9,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Announcing the OpenBao Blog!","description":"OpenBao Blog Kickoff - Focused on the Community and Technical Challenges","slug":"kickoff","authors":"cipherboy","tags":["intro","trends","community"],"image":"https://raw.githubusercontent.com/openbao/artwork/main/color/openbao-text-color.svg"},"unlisted":false,"prevItem":{"title":"Profiles for Cross-Plugin Communication","permalink":"/blog/profiles"},"nextItem":{"title":"Announcing OpenBao v2.0.0, the Initial GA Release!","permalink":"/blog/release-v2-0-0"}},"content":"We asked one of our Gen Z community members to describe OpenBao recently. They wrote the following:\\n\\n\x3c!-- truncate --\x3e\\n\\n> <p align=\\"center\\"><img src=\\"https://raw.githubusercontent.com/openbao/artwork/main/color/openbao-color.svg\\" alt=\\"OpenBao Logo\\" height=\\"30%\\" width=\\"30%\\" /></p>\\n>\\n> See the three bao representing different [auth](/docs/auth/) and [secret](/docs/secrets/) [engines](/docs/plugins/) or nodes in a [cluster](/docs/concepts/ha/)? Very _cutesy_.\\n>\\n> See how secrets can be [dynamically](/docs/use-cases/#dynamic-secrets) [rotated](/docs/secrets/databases/)? Very _considerate_.\\n>\\n> See our project running under [open governance](https://github.com/openbao/openbao/blob/main/CONTRIBUTING.md#technical-steering-committee-tsc-members) and with [OSI licenses](https://github.com/openbao/openbao/blob/main/LICENSE)? Very _mindful_.\\n>\\n> See us promise [API compatibility](/community/policies/migration/#proposal) with drop-in compatibility for Raft users? Very _respectful_.\\n>\\n> See all of the nicely packaged [release binaries](/downloads/) ready for [installation](/docs/install/)? [Very _demure_](https://www.nytimes.com/2024/08/14/style/demure-tiktok-mindful-cutesy.html).\\n\\n---\\n\\nNot all [trends](https://www.mongodb.com/legal/licensing/server-side-public-license/faq) are worth jumping on.\\n\\nWhile attackers have only gotten [more](https://www.pcmag.com/news/microsoft-details-how-chinese-hackers-acquired-signing-key-for-outlook) [sophisticated](https://www.npr.org/2021/04/16/985439655/a-worst-nightmare-cyberattack-the-untold-story-of-the-solarwinds-hack), the importance of central inventory, observability, and facilitating organization-wide rotation of secrets can make the difference in a proactive security posture. More than that, being confident that your solution won\'t disappear over night because of a license change ensures long-term peace of mind and stability.\\n\\nThat\'s why OpenBao was launched with open governance [under the Linux Foundation\'s LF Edge](https://lfedge.org/projects/openbao/).\\n\\n**Join the community and its leadership today.**\\n\\n:::info\\n\\nWelcome to the start of our blog series.\\n\\nAt the end of every blog post, we\'ll post a way you can get involved based on the topics discu
1ssed.\\n\\nInterested in writing a blog post with us? Feel free to [reach out](https://github.com/openbao#contact), we\'d love to see what you have in mind!\\n\\nIf you\'re looking for ideas, consider talking about your experience as an operator of OpenBao and deploying it, or as a developer or architect integrating and designing against it. Or maybe consider writing about an existing or upcoming feature you\'re excited about.\\n\\n:::"},{"id":"release-v2-0-0","metadata":{"permalink":"/blog/release-v2-0-0","source":"@site/content/blog/2024-07-25-release-v2-0-0.mdx","title":"Announcing OpenBao v2.0.0, the Initial GA Release!","description":"We are thrilled to announce the availability of OpenBao v2.0.0, its initial GA release!","date":"2024-07-25T00:00:00.000Z","tags":[{"inline":true,"label":"release","permalink":"/blog/tags/release"},{"inline":true,"label":"announcement","permalink":"/blog/tags/announcement"},{"inline":true,"label":"release","permalink":"/blog/tags/release"}],"readingTime":2.48,"hasTruncateMarker":true,"authors":[{"name":"Alex Scheel","url":"https://cipherboy.com","socials":{"github":"https://github.com/cipherboy","linkedin":"https://www.linkedin.com/pub/alexander-scheel/105/514/807","mastodon":"https://infosec.exchange/@cipherboy"},"imageURL":"https://cipherboy.com/img/alex-2026-small-square.jpg","key":"cipherboy","page":null}],"frontMatter":{"title":"Announcing OpenBao v2.0.0, the Initial GA Release!","description":"We are thrilled to announce the availability of OpenBao v2.0.0, its initial GA release!","slug":"release-v2-0-0","authors":"cipherboy","tags":["release","announcement","release"],"image":"https://lfedge.org/wp-content/uploads/sites/24/2024/07/Screenshot-2024-07-24-at-12.49.18-PM.png"},"unlisted":false,"prevItem":{"title":"Announcing the OpenBao Blog!","permalink":"/blog/kickoff"}},"content":"import Head from \'@docusaurus/Head\';\\n\\n<Head>\\n <link rel=\\"canonical\\" href=\\"https://lfedge.org/announcing-openbao-v2-0-0-the-initial-ga-release/\\" />\\n</Head>\\n\\n\\n\\nWe are thrilled to announce the availability of [OpenBao v2.0.0](/community/release-notes/2-0-0/), its initial GA release!\\n\\nIt was fabulous to see contributors and member companies from a wide range of backgrounds come together to support OpenBao over the past several months and build an initial GA release in the open. This release focuses mostly on stabilizing the fork, reducing the binary size, and giving the community room to make the decisions it needs to ensure a healthy start to the ecosystem.\\n\\n\x3c!-- truncate --\x3e\\n\\n## Key highlights of the release\\n\\nMajor features:\\n\\n - **Paginated Lists**: Allow plugins to support pagination on LIST requests, reducing server and client burden by limiting large responses. This uses optional after and limit parameters for clients to control the size of responses with a relative indexing into result entry sets.\\n\\nPlugin improvements:\\n\\n - `secret/pki`: Add Delta CRL Distribution Point to AIA URLs, allowing AIA-aware clients to find Delta CRLs dynamically.\\n - `sdk/helper/shamir`: move Shamir\u2019s code into public SDK namespace to encourage external reuse\\n - `core`: Remove mlock functionality from OpenBao and make the \u201Cdisable_mlock\u201D config option obsolete.\\n - `secret/transit`: Add support for XChaCha20-Poly1305 keys, preventing nonce-reuse without key rotation.\\n - `secret/transit`: Allow choosing export key format, specifying format=der or format=pem for consistent PKIX encoded public keys.\\n - `secret/transit`: Allow soft deletion of keys, preventing their use and rotation but retaining key material until restored or fully deleted.\\n - `secret/rabbitmq`: Fix role reading causing audit log panic when vhost_topics are set.\\n - `secret/pki`: Use user-submitted ordering for SANs, fixing issues where automatic ordering causes parse failures in some browsers.\\n - `auth`: Add token_strictly_bind_ip to support strictly binding tokens to source IP address.\\n\\nStay tuned for more great features to come!\\n\\n\\n\\n## Looking ahead\\n\\nAs the community matures and puts processes in place for project leadership, we\u2019re looking for contributors to help maintain the external plugin ecosystem with the fork. If you\u2019re willing to help out, check out [https://github.com/openbao/openbao/issues/134](https://github.com/openbao/openbao/issues/134)!\\n\\nWe\u2019ve also already seen some fairly ambitious contributions from the community for the next release, from PKCS#11 and KMIP auto-unseal methods, to transactional storage, and to overall improvements in the JWT/OIDC authentication method. Additionally there\u2019s been great progress on forking the Kubernetes ecosystem tooling and we expect that to GA soon.\\n\\n---\\n\\nThis blog post was originally posted on the [LF Edge Blog](https://lfedge.org/announcing-openbao-v2-0-0-the-initial-ga-release/).\\n\\nCheck out our website and follow [LF Edge on LinkedIn](https://www.linkedin.com/company/lf-edge/) to keep up to date on the latest, and learn how you can participate!"}]}}')}}]);
Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.