[jira] [Commented] (GUACAMOLE-2137) Introduce HashiCorp Vault token handler (based on the KSM module)

["Nick Couchman (Jira)" <ji...@apache.org>]

    [ 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)