[
https://issues.apache.org/jira/browse/NIFI-15208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard resolved NIFI-15208.
-----------------------------------
Fix Version/s: 2.7.0
Resolution: Fixed
> HashiCorpVaultParameterProvider caches service causing configuration changes
> to be ignored
> ------------------------------------------------------------------------------------------
>
> Key: NIFI-15208
> URL: https://issues.apache.org/jira/browse/NIFI-15208
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Affects Versions: 1.18.0, 1.19.0, 1.20.0, 1.19.1,
> nifi-nar-maven-plugin-1.5.0, 1.21.0, 1.22.0, 1.23.0, 1.24.0, 1.23.1, 1.23.2,
> 1.25.0, 1.26.0, 1.27.0, 1.28.0, 2.0.0, 2.1.0, 1.28.1, 2.2.0, 2.3.0, 2.4.0,
> 2.5.0, 2.6.0
> Reporter: Ghislain LE MEUR
> Assignee: Ghislain LE MEUR
> Priority: Minor
> Labels: patch, pull-request-available
> Fix For: 2.7.0
>
> Attachments: fix-hashicorp-vault-parameter-provider.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> +*Summary*+
> The _*HashiCorpVaultParameterProvider*_ caches the
> *_vaultCommunicationService_* in an instance variable, which is never
> invalidated when the underlying _*HashiCorpVaultClientService*_ configuration
> is modified. This causes the Parameter Provider to continue using stale
> credentials even after they have been changed or revoked.
> +*Impact*+
> *Security Risk:*
> - Revoked or expired Vault tokens continue to work
> - Configuration changes (token rotation, Vault URI changes) are not reflected
> - Only a NiFi restart forces the cache to be cleared
> *Affected Versions:*
> - All versions from 1.18.0 onwards (when _*HashiCorpVaultParameterProvider*_
> was introduced)
> - Confirmed on versions 2.4.0 and 2.6.0
> *Steps to Reproduce*
> 1. Create and enable a _*StandardHashiCorpVaultClientService*_ with a valid
> _*vault.token*_
> 2. Create a _*HashiCorpVaultParameterProvider*_ that references this service
> 3. Perform a _*Fetch Parameters*_ operation → *Success* (expected)
> 4. Disable the Vault Client Service
> 5. Modify the _*vault.token*_ property to an invalid value (e.g.,
> "INVALID-TOKEN-12345")
> 6. Re-enable the Vault Client Service
> 7. Perform another "Fetch Parameters" operation
> +*Expected Behavior:*+
> The fetch should *_fail_* with a 403 Forbidden error due to the invalid token.
> {+}*Actual Behavior*{+}:
> The fetch _*succeeds*_ because the Parameter Provider continues using the
> cached service with the old valid token.
> +*Root Cause*+
> The _*HashiCorpVaultParameterProvider*_ class stores the
> _*vaultCommunicationService*_ as an instance variable:
>
> {code:java}
> private HashiCorpVaultCommunicationService vaultCommunicationService;{code}
>
> This variable is initialized once and reused for all subsequent fetch
> operations. Even though an *_onPropertyModified()_* method attempts to
> invalidate the cache by setting it to null, this is insufficient because:
> 1. Property changes in the referenced Controller Service don't trigger
> _*onPropertyModified()*_ in the Parameter Provider
> 2. The invalidation only occurs for direct property changes, not for changes
> in referenced services
> +*Proposed Solution*+
> Remove the instance variable cache and retrieve a fresh service instance on
> every _*fetchParameters()*_ call.
> This ensures configuration changes are immediately reflected.
> Changes required:
> 1. Remove the instance variable *_vaultCommunicationService_*
> 2. Remove the _*onPropertyModified()*_ method
> 3. Call _*getVaultCommunicationService(context)*_ directly in
> _*fetchParameters()*_ and _*verify()*_
> +*Verification*+
> A fix has been tested on versions 2.4.0 and 2.6.0 with the following results:
> - Configuration changes are immediately reflected
> - Invalid tokens correctly result in 403 Forbidden errors
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
