Support username/password credentials stored as JSON formatted secret about aws-secrets-manager-credentials-provider-plugin HOT 5 CLOSED

Just noticed, that you document a work-around under advanced usage using a string secret type and readJSON. Unfortunately this approach does not work in places where we cannot add custom credential post-processing.

from aws-secrets-manager-credentials-provider-plugin.

Which places are you unable to add custom credential post-processing for? I ask because our teams at work that use JSON values for credentials have been able to achieve what they want with the readJson snippet, from the readme.

from aws-secrets-manager-credentials-provider-plugin.

We use a few Jenkins plugins that we configure via CasC yaml, which need direct references to credentialIds. (One recent example which triggered me to create this issue: The influxdb plugin migrated from plain username/password to credentialId.)

We could probably replace all global plugin configuration with job-local configuration (using the readJson approach), so it's not impossible to do, but it feels like a work-around for a rather common case?

from aws-secrets-manager-credentials-provider-plugin.

The reason this is unfortunately not possible is that the username field has to be supplied when credentials are listed, as well as when they are used in a job. The credentials list is populated with a ListSecrets call (the result is cached for 5 mins). This is to ensure that the performance is reasonable, and to avoid unnecessarily exposing secret values (which GetSecretValue would do). The only way to supply non-secret fields like the username in a way that ListSecrets can show them, is to store those fields as AWS tags on the secret.

I get where you're coming from - it would be nice if different tools would share secrets more easily - but alas the credentials API doesn't provide wiggle room here.

from aws-secrets-manager-credentials-provider-plugin.

@chriskilding Hm, thanks very much for your analysis. What do you think of the following compromise:

If all our json secrets additionally had a jenkins:credentials:username tag duplicating the username found in the username json field, we would still be able to use the same secret entry for multiple tools (and also use the regular password rotation lambdas). While the password value changes regularly, the username value is mostly a constant, so we don't really lose much from a maintenance stand-point.

The jenkins plugin would use the regular username tag for ListSecrets and only need to parse the json for GetSecretValue.
(The json mode could be activated by specifying some sort of jenkins:credentials:passwordFieldName tag.)

from aws-secrets-manager-credentials-provider-plugin.