Replace db password placeholder in application.yaml for MP with value fetched from OCI vault secret.

[vjaiswal1]

Environment Details

• Helidon Version:
• Helidon MP
• JDK version: 11

---

Problem Description

• Consider this configuration of datasource where password is hardcoded.
  javax:
  sql:
  DataSource:
  slDataSource:
  dataSourceClassName: org.h2.jdbcx.JdbcDataSource
  dataSource:
  url: jdbc:h2:mem:slPU
  user: sa
  password: "XXX"
• We want to replace this hardcoded password value at runtime while application starts with value being fetched from OCI vault secret.

[klustria]

I have created a sample Helidon MP application that uses Custom Config Source and Oci Vault in https://github.com/klustria/helidon-mp-custom-config-oci-vault. The project is well documented so hopefully it provides answer to this issue.

[klustria]

Project https://github.com/klustria/helidon-mp-custom-config-oci-vault is updated to provide commented out sample of getSecretBundleByName() usage if that is the preferred way.

[klustria]

New update was pushed into the project https://github.com/klustria/helidon-mp-custom-config-oci-vault to simplify config parsing of the oci parameters from within the custom config source. Please pull the latest update.

[klustria]

Please provide update, i.e. let me know if this solves your issue so I can close it.

[vjaiswal1]

it worked well. one suggestion was given by one of my team member if we can incorporate those changes.

"With the current implementation, following limitations are observed due to which module cannot be re-used as dependencies in other services:

1. Need to define property in application.yaml to specify secret-name for each secret to be fetched from OCI vault.
2. Manually mapping needs to be updated in PROPERTIES of ConfigSource

Desirable Way: Able to use the secret-name directly against property, similar to using ENV variable
I thought about the changes for the approach, where we can directly use the OCI vault secret-name in the application.yaml to map it to the property.

I think with below changes it can be made as generic jar, with OCI vault secret name directly used in application.yaml

1. Get all secrets list or defined a property which specify lists of secret-name required for the application.
2. Set the PROPERTIES, with oci vault secret's name and value
3. In application yaml, use the secret name against the intended key
   jenkins.user: ${oci_auth_user_jenkinsuser_svc_dev}

Simpler, yet configurable: Able to define mapping of property and secret-name via configuration, instead in source code
For quicker implementation, we can also take a middle approach, where application yaml will define a map of property:secret-name, resembling the map to be defined under PROPERTIES in ConfigSource. This would not need to define custom key value, for each secret to be fetched and the ConfigSource.PROPERTIES will be configurable using yaml.
For example:

oci:
secret:
    mapping:
      jenkins.user: oci_auth_user_jenkinsuser_svc_dev

Now iterate over this map and populate the PROPERTIES map in ConfigSource."

[klustria]

We will evaluate with OCI Vault as a Config source in #4238.

[ljnelson]

This is now possible with the resolution of #4238 (see #7520, #7555, #7481, #7470, etc.)