[
https://issues.apache.org/jira/browse/GUACAMOLE-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18102604#comment-18102604
]
Nick Couchman commented on GUACAMOLE-2137:
------------------------------------------
Just to add context to this - OpenBao is a fork of HashiCorp Vault at the point
at which IBM took it over and changed the licensing from the more open licenses
that they had classically used to the BUSL, which is a more restrictive license
that allows you to *use* the HashiCorp Vault software as long as that use of it
is not competing with IBM's commercial offerings. Thus, OpenBao and HashiCorp
Vault are, at the moment, compatible products. There's no guarantee that this
will remain the case going forward, so Guacamole may have to split that out at
some point in the future when the code bases diverge enough to matter.
> Introduce HashiCorp Vault token handler (based on the KSM module)
> -----------------------------------------------------------------
>
> Key: GUACAMOLE-2137
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-2137
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-vault
> Reporter: TdlQ
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0 [main]
>
>
> This introduces a new module to handle HashiCorp Vault tokens. It is heavily
> inspired by and reuses a significant amount of code from the existing KSM
> module.
> The main goal is to provide a dedicated, lightweight solution for fetching
> secrets from HashiCorp Vault for use in Guacamole connection parameters. This
> allows for replacing static credentials with dynamic, centrally managed
> secrets.
> h3. Key Features & Implementation Details
> * Token Format: The module uses a new token format,
> ${HASHIVAULT:path/to/secret/key}, to reference secrets stored in Vault. For
> example: Password:
> ${HASHIVAULT:path/to/my/server/guacamole_connection/password}.
> * Centralized Configuration: Vault configuration is managed through a
> base64-encoded JSON object (vault_url, vault_token, cache_lifetime), which is
> stored in the HV_CONFIG parameter and can be overridden at connection groups
> level.
> * Efficient Caching: The module is optimized for performance. When multiple
> tokens reference the same Vault path (e.g., username and password from the
> same secret), it performs only a single HTTP query to Vault. Subsequent
> requests for keys within the same path are served directly from a concurrent,
> time-based cache.
> * Asynchronous Handling: All Vault queries are performed asynchronously to
> prevent blocking the connection process. This is achieved using
> CompletableFuture and a "in-flight" request caching pattern to handle
> concurrent requests for the same secret efficiently.
> h3. Notable Differences and Design Choices (vs KSM)
> * Simplicity: This module is designed to be a simpler, more lightweight
> alternative to the KSM module, focusing exclusively on basic token handling.
> It intentionally lacks more advanced features.
> * Execution Order: The setAttributes() method now directly calls
> processAttributes() to ensure correct execution order, which was an issue
> observed during development.
> * User Custom Configuration: The user-defined configuration part is
> currently a placeholder. It mimics KSM's design but might be simplified or
> removed in the future if a clear use case for it does not emerge.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
