[
https://issues.apache.org/jira/browse/GUACAMOLE-2137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097350#comment-18097350
]
Ciro Iriarte commented on GUACAMOLE-2137:
-----------------------------------------
Cross-referencing the PR history, since it is spread across several PRs and is
not visible from the ticket.
The active PR is [#1216|https://github.com/apache/guacamole-client/pull/1216],
which supersedes both
[#1116|https://github.com/apache/guacamole-client/pull/1116] (this ticket) and
[#1143|https://github.com/apache/guacamole-client/pull/1143] (GUACAMOLE-2196,
OpenBao). It supports OpenBao and HashiCorp Vault in a single
guacamole-vault-hv module mirroring the structure of the shipped KSM module,
and covers the KV v1/v2, LDAP, SSH, and database secret engines.
Note the ticket title refers only to HashiCorp, but this is now also the home
of OpenBao support (GUACAMOLE-2196). Linking the two so either search term
finds the active work.
Two items on #1216 likely to need committer input before it can be reviewed in
earnest:
# It modifies core TokenFilter in guacamole-ext to widen the parameter token
grammar, including a signature change to the public getToken() method. That
affects all extensions, not just this one. Characterization tests for the
existing grammar are proposed in GUACAMOLE-2302 / [PR
#1231|https://github.com/apache/guacamole-client/pull/1231].
# A design question on whether Vault paths should appear directly in connection
parameters, or go through a mapping-file indirection as the KSM extension does.
Detailed comments left on the PR.
> 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)
