## Summary
Request an IBM Liberty enhancement to let applications (including IBM Dynamic Workload Console running on Liberty) reference database credentials from an external secrets source (e.g., CyberArk/HashiCorp Vault) or secure system store. This would remove the need for a static password value in a Liberty datasource configuration file (e.g., .../configDropins/overrides/datasource.xml).
## Background & Prior Vendor Engagement
A prior IBM support case confirmed that Dynamic Workload Console currently supports only static passwords for the database connection.
An IBM Ideas/RFE submission advised this requirement should be raised against IBM Liberty (not the workload scheduling product), as the datasource capability is provided by Liberty.
Dynamic Workload Console runs on IBM Liberty, and database credentials are configured via Liberty datasource settings in datasource.xml.
## Business & Security Rationale
Static passwords in configuration files create a persistent risk surface (even when encrypted) and make rotation/revocation harder.
Target state is alignment with enterprise security practices: centralised credential management, frequent rotation, auditable access, and least privilege.
A Liberty-native approach reduces operational burden and improves security posture.
## Requested Enhancement (Functional Requirement)
Provide Liberty-native capability for JDBC datasource password resolution that:
Retrieves the password at runtime from an external secret provider or secure store (e.g., CyberArk, HashiCorp Vault), without embedding the password value in datasource.xml.
Supports credential rotation without requiring a Liberty server restart or manual file edits.
Ensures the resolved secret is never exposed in logs or administrative consoles in plain text.
Maintains compatibility with existing Liberty datasource/JDBC features and Dynamic Workload Console database connectivity.
## Technical Context
Current state: datasource definitions include a static password value in datasource.xml.
Desired state: datasource.xml contains only a reference/alias; Liberty resolves the actual secret from a configured provider at runtime.
Provider-specific details (Vault path, CyberArk API usage, token provisioning) can be supplied once Liberty supports a standard integration mechanism (feature/extension point/SPI).
## Acceptance Criteria
Liberty supports configuring a JDBC datasource with a secret reference rather than a literal password value.
Password rotation is possible without manual file changes and without exposing plain text secrets.
Works with Dynamic Workload Console on Liberty across supported SQL Server JDBC driver versions.
Documented setup steps and sample configuration showing integration with at least one external secrets source, or a pluggable SPI enabling third‑party providers.
## Impact
Security: Eliminates a persistent static credential from application config; reduces leakage risk; supports centralised audit and control.
Operations: Simplifies rotation; reduces manual changes and outage risk; improves compliance readiness.
