Hello,
I first wanted to say thank you for putting this plugin together.
Secondly, this implementation is different than how we have tried to solve this so, maybe my suggestion is incompatible.
We are using a very crude method to handle pulling secrets from AWS Secrets Manager and creating the Jenkins Credentials for them. Our solution is to create a file ("init.groovy.d/credential-x.groovy") which executes aws cli command to retrieve the secret value for the supplied secret ARN. This file is generated from an Ansible template where we pass in the credential name and ARN, such that there exists one file per credential. In Ansible we have different templates for the different credential implementations, e.g. "AWSCredentialsImpl", "StringCredentialsImpl", "BasicSSHUserPrivateKey", etc. The downside to this is that the secret is only updated once Jenkins reboots or the script gets ran manual via Script Console or similar.
To restate, we have a specific ARN mapped to a specific Credential Implementation.
Again, I know this is somewhat at odds to this plugin implementation but I think it could be beneficial to allow the end user to create the mappings of ARN and then have a schema for each Implementation.
Hi Enrique,
This is a feature I’ve been musing on for a little while. As I see it, there’s a few different solutions possible.
I initially developed the plugin with just the Secret Text credential Type for the following reasons:
Point 4 is probably the strongest reason not to support multiple credential types in the AWS Secrets Manager provider. If we invent a Jenkins-proprietary schema for complex credential types eg SSH key (username, key, passphrase (optional)), only Jenkins will understand it, and we’ll have to either duplicate that credential for our other applications, or update them all to understand the Jenkins credential schema.
However... this is a tricky architectural problem. There’s probably not a single perfect answer to it. I’d be interested to hear other views on this