NIFI-16260 - Add a Database Password Provider for GCP CloudSQL

[pvillard31]

Summary

NIFI-16260 - Add a Database Password Provider for GCP CloudSQL

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for putting together this new feature @pvillard31.

The basic implementation looks good, but I noted a few questions and concerns around the validation and testing.

Although the detailed introspection of the Connection URL can certainly help catch issues, it adds quite a bit of implementation and test code. I'm particularly concerned about the weight of the "legacy" parameters, which seem unnecessary to check. I recommend scoping down some of the verification steps as one way forward.

[pvillard31]

Thanks for the review. I simplified the implementation substantially and removed the database-specific validation from the password provider. The provider now focuses only on obtaining, scoping, caching, refreshing, and returning the Cloud SQL IAM token. JDBC URL, driver, username, and TLS configuration remain the responsibility of the DBCP service and JDBC driver.

I also removed the exception stack-trace introspection and reduced the tests to the essential credential lifecycle, refresh, verification, and failure-handling behavior. The focused tests, complete GCP processor module suite, Checkstyle, RAT, and PMD all pass. I also completed final live validation with both PostgreSQL and MySQL.

[exceptionfactory]

Thanks for making the adjustments @pvillard31, this looks close to completion. I highlighted a few remaining recommendations.

[pvillard31]

Thanks for the review @exceptionfactory - I pushed a commit to address your feedback

[exceptionfactory]

Thanks for the update @pvillard31, this looks better, I noted a few additional recommendations.

[exceptionfactory]

It looks like this rejects other kinds of credentials like ExternalAccountCredentials, is that intentional?

[pvillard31]

The check specifically rejected IdentityPoolCredentials, rather than every ExternalAccountCredentials subtype, but that was still an unnecessarily restrictive implementation-specific check. I removed the class-based rejection from enablement, verification, and password generation. The provider now applies the Cloud SQL login scope and lets actual token acquisition determine whether the supplied GoogleCredentials implementation is compatible.

[exceptionfactory]

With the verificationLogger passed in but not used, it would be helpful to pass it down to some of the nested methods and log the exceptions thrown, instead of just returning null for verification.

[pvillard31]

done