mattcasters commented on issue #7326:
URL: https://github.com/apache/hop/issues/7326#issuecomment-4835154355
# OpenBAO and HashiCorp Vault Compatibility Analysis for Apache Hop
This report analyzes the compatibility between **OpenBAO** and **HashiCorp
Vault**, identifies why existing clients or drivers (like the one used in Hop)
might face issues, and outlines the pros and cons of implementing a dedicated
OpenBAO variable resolver.
---
## 1. Context: What is OpenBAO?
**OpenBAO** is an open-source, community-governed secrets management
platform created as a fork of HashiCorp Vault (specifically version 1.14.0)
after HashiCorp transitioned Vault to the restrictive **Business Source License
(BSL 1.1)** in August 2023. OpenBAO is hosted under the **Linux Foundation's
Open Source Security Foundation (OpenSSF)** and is licensed under the **Mozilla
Public License (MPL 2.0)**, maintaining a commitment to pure open-source
principles.
---
## 2. Why OpenBAO and HashiCorp Vault Aren't Fully Client-Compatible
While OpenBAO's core design goal is to remain API and CLI
backward-compatible with HashiCorp Vault 1.14.0, several practical differences
and long-term divergence trends can cause client-side incompatibility or
unexpected behavior:
### A. Divergence Since the Fork (Vault 1.15+ vs. OpenBAO)
- **Codebase Divergence**: HashiCorp Vault has released versions 1.15, 1.16,
1.17, etc., introducing new capabilities, updated API schemas, and modified
endpoints. OpenBAO does not inherit these changes. Instead, it is developing
its own independent roadmap.
- **Feature Set Gaps**: Proprietary enterprise features (like Sentinel
policy engine or advanced replication) are absent in OpenBAO or replaced with
open-source alternatives (like Common Expression Language (CEL)).
### B. Token Prefix Formats
- HashiCorp Vault generates tokens with specific prefixes such as `hvs.`
(service tokens), `hvb.` (batch tokens), and `hvr.` (recovery tokens).
- OpenBAO generates tokens with its own prefixes, starting with `sbr.`
(e.g., `sbr.X...`).
- **Impact**: Any client SDK, driver, or custom middleware code that
strictly validates token lengths, entropy, or expects the standard Vault
prefixes will reject OpenBAO tokens as invalid.
### C. Open-Source Namespaces
- In HashiCorp Vault, **Namespaces** (hierarchical tenant structures) are
strictly an **Enterprise-only** feature.
- OpenBAO provides namespaces in its **free and open-source** release.
- **Impact**: Clients/drivers built for the community edition of HashiCorp
Vault often do not expose namespace header fields (like `X-Vault-Namespace`),
making it impossible for open-source users to access partitioned secrets in
OpenBAO without upgrading to a client configured for enterprise features.
### D. Obsolete Client Library in Hop
- Apache Hop currently uses the `com.bettercloud:vault-java-driver:2.0.0`
library.
- This library has been **abandoned and unmaintained since December 2019**.
- It was written for older Vault API specifications. When communicating with
modern Vault/OpenBAO endpoints, mismatching assumptions about KV Secrets Engine
paths (specifically KV v1 vs KV v2 `/data/` nesting) can cause `404 Not Found`
API responses or fail silently to resolve variables (returning the unresolved
placeholder `#{openbao:kv/foo:bar}`).
---
## 3. Pros and Cons of a Dedicated OpenBAO Resolver in Hop
| Factor | Pros | Cons |
| :--- | :--- | :--- |
| **Open Source & Licensing** | **Perfect Alignment**: Apache Hop (ASL 2.0)
aligns naturally with OpenBAO (MPL 2.0). Users can maintain a 100% open-source
stack without relying on BSL-restricted vendor components. | **No SDK
Differentiation**: OpenBAO currently relies on the same community Java clients
as Vault. Under the hood, Hop will use similar or identical drivers for both. |
| **Namespace Support** | **Exposed in UI**: Hop can easily add a
"Namespace" field in the OpenBAO resolver UI. In HashiCorp Vault, this is
usually hidden or omitted in free-tier integrations. | **Code Duplication**:
Since the REST endpoints are almost identical, copying the resolver code leads
to duplicate boilerplate and increased maintenance burden. |
| **Independent Evolution** | **Future-Proofing**: A separate resolver
allows Hop to adapt as OpenBAO's roadmap diverges further from Vault (e.g. new
auth methods, backend configs) without breaking existing Vault integrations. |
**User Confusion**: Having two separate resolvers ("HashiCorp Vault" and
"OpenBAO") that look almost identical in the UI could confuse users. |
| **Dependency Modernization** | **Driver Upgrade**: Creating a new resolver
provides an opportunity to use a modern, active driver (like
`io.github.jopenlibs:vault-java-driver`) which solves old bugs and adds modern
auth (OIDC, Kubernetes). | **Double Testing**: Maintaining, testing, and fixing
bugs across two distinct codebases increases the testing surface for Hop
developers. |
---
## 4. Implementation Recommendations
To support OpenBAO effectively while keeping Hop's codebase clean:
1. **Avoid Full Code Duplication**:
- Create an abstract base class `BaseVaultVariableResolver` (or helper
utilities) in a shared module.
- Extend this base class to create `VaultVariableResolver` and
`OpenBaoVariableResolver`.
2. **Modernize the Driver**:
- Replace the obsolete `com.bettercloud` dependency in the Vault plugins
POM with the community-maintained `io.github.jopenlibs:vault-java-driver`
(v5.2.0+).
3. **Introduce Namespace Support**:
- Add a `namespace` configuration parameter to the base class, exposing
it in both resolvers. This directly benefits OpenBAO users and Vault Enterprise
users alike.
4. **Distinguish in UI**:
- Group them under logical names ("HashiCorp Vault Variable Resolver" vs.
"OpenBAO Variable Resolver") to clearly signal compatibility and community
alignment.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
