My coworker had an interesting take on this. He suggested that when he's writing a CasC YAML file and needs to specify a secret key for something, he would like the ability to reference a Jenkins credential's ID in the value slot, with some kind of interpolation syntax.

The high level result would be that any credential, from any provider, could be used to fill in the secret value for that CasC entry.

chriskilding while your coworker idea is great. There will be a problem between configuring said provider and at the same time using that provider to reveal secrets.

However this should be possible to solve to always configure credentials provider first and then have a secret resolver use the credentials provider

Since Secrets Manager is a distinct service from Parameter Store, they should probably continue to be handled by different plugins.

However, it could make sense to add a Secrets Manager SecretSource implementation to this plugin, so that CasC can populate all secrets from Secrets Manager - not just the ones that can be referenced through the CredentialsProvider API. (I'm thinking of the bootstrapping secrets that CasC can't get from a CredentialsProvider.) This would be the counterpart of the Parameter Store SecretSource implementation in the ssm plugin.

Thoughts?

I have written up the feature description in JENKINS-61291

0.3.0 added a Secrets Manager based SecretSource. This would make a direct merge of our plugins unwieldy, as it would put both Parameter Store and Secrets Manager in play. For as long as we have multiple plugins for AWS services, it's probably best to have one AWS service per plugin, so that plugins don't need to handle conditional activation of services.

The continuing work on the Jenkins BOM would address how to pull in the AWS SDK without conflicts between plugins. The BOM would be the right place to set the SDK version, and then both our plugins would need to use the BOM.

To be continued in JENKINS-60879...