[
https://issues.apache.org/jira/browse/GUACAMOLE-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman updated GUACAMOLE-2137:
-------------------------------------
Fix Version/s: 1.7.0
(was: 1.6.1)
> 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
> Fix For: 1.7.0
>
>
> 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)
