Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-61938

Can aws-secrets-manager-credentials-provider-plugin be configured to use a credential binding for authentication?

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      It seems like the AWS-secrets-manager-credentials-provider-plugin plugin assumes your running on EC2 (with a role) or have injected aws creds via env vars directly into the master's session

      Id like to just configure access via a credential binding like I can for most of the other plugins

      So I can tell the aws-secrets-manager-credentials-provider-plugin which cred binding to use which has AWS access keys with read access to Secrets Manager

        Attachments

          Activity

          Hide
          chriskilding Chris Kilding added a comment -

          Could you share some example pipeline scripts to show what you're trying to set up?

          Show
          chriskilding Chris Kilding added a comment - Could you share some example pipeline scripts to show what you're trying to set up?
          Hide
          red888 red der added a comment - - edited

          Im realizing this is probably impossible with this plugin as it uses AWS secrets manager as a more static backend then what I think I want for my purposes

          My goal is to separate my dev and prod secrets in different aws accounts (I do this now with secrets manager)

          The secret objects have the same name in dev and prod. So If you want to access the dev or prod secrets you just assume a role or IAM user with dev or prod access and there is nothing else to configure

          To do this with jenkins I would want to be able to dynamically switch the account used to retrieve the secrets- so a pipeline for example might look something like:

           

           // some way to set credentials dynamically during a pipeline run 
           // I have different configs with dev or prod credentials and can switch between them 
           secrets-manager-plugin-config = "${params.ENVIRONMENT=='production' ? 'prod-config':'dev-config'}"
           def secrets-manager-plugin = secrets-manager-plugin.config secrets-manager-plugin-config
           // or maybe there is another way to have the master assume a different role during a build?
          
          
           // for example with the artifactory plugin you can do this
           artifactory-config = "${params.ENVIRONMENT=='production' ? 'prod-config':'dev-config'}"
           // the plugin can be configured inside of pipelines to use different configs
           // "prod-config" and "dev-config" are configured in jenkins server settings and use credential bindings for the username and password
           def artifactory = Artifactory.server artifactory-config
          
          
           // then at pipeline level or in stages I reference the secrets with credentials()
           // I dont need to conditionally switch between SOME_SECRET_A_DEV and SOME_SECRET_A_PROD 
           // I just switch the role/iam user and jenkins gets the dev or prod secrets for me using an account that has dev or prod secret access
           pipeline {
           environment {
           SOME_SECRET_A = credentials('SOME_SECRET_A')
           SOME_SECRET_B = credentials('SOME_SECRET_B')
           }
          ....
          

           

          Show
          red888 red der added a comment - - edited Im realizing this is probably impossible with this plugin as it uses AWS secrets manager as a more static backend then what I think I want for my purposes My goal is to separate my dev and prod secrets in different aws accounts (I do this now with secrets manager) The secret objects have the same name in dev and prod. So If you want to access the dev or prod secrets you just assume a role or IAM user with dev or prod access and there is nothing else to configure To do this with jenkins I would want to be able to dynamically switch the account used to retrieve the secrets- so a pipeline for example might look something like:   // some way to set credentials dynamically during a pipeline run // I have different configs with dev or prod credentials and can switch between them secrets-manager-plugin-config = "${params.ENVIRONMENT== 'production' ? 'prod-config' : 'dev-config' }" def secrets-manager-plugin = secrets-manager-plugin.config secrets-manager-plugin-config // or maybe there is another way to have the master assume a different role during a build? // for example with the artifactory plugin you can do this artifactory-config = "${params.ENVIRONMENT== 'production' ? 'prod-config' : 'dev-config' }" // the plugin can be configured inside of pipelines to use different configs // "prod-config" and "dev-config" are configured in jenkins server settings and use credential bindings for the username and password def artifactory = Artifactory.server artifactory-config // then at pipeline level or in stages I reference the secrets with credentials() // I dont need to conditionally switch between SOME_SECRET_A_DEV and SOME_SECRET_A_PROD // I just switch the role/iam user and jenkins gets the dev or prod secrets for me using an account that has dev or prod secret access pipeline { environment { SOME_SECRET_A = credentials( 'SOME_SECRET_A' ) SOME_SECRET_B = credentials( 'SOME_SECRET_B' ) } ....  
          Hide
          chriskilding Chris Kilding added a comment - - edited

          Have you had a look at the custom clients feature of the plugin? It's available in the released version, currently behind a beta flag. It allows the plugin to do ListSecrets with multiple custom AWS SDK clients.

          For example, this would allow you to specify two profiles "staging" and "production" in the ~/.aws/config and credentials files on your Jenkins box, and use both of them in the Secrets Manager ListSecrets call. The provider will then present one big list of credentials from both clients:

          unclassified:
            awsCredentialsProvider:
              beta:
                clients:
                  - credentialsProvider:
                      profile:
                        profileName: "staging"
                  - credentialsProvider:
                      profile:
                        profileName: "production"
          

          You can also set the region and endpointConfiguration per-client if you wish.

          When custom clients mode is enabled, credentials from the Secrets Manager provider currently use the secret ARN as their ID (rather than the secret name) to ensure there are no collisions between secrets from different accounts.

          More info in the docs

          Let me know if this is the kind of thing you're looking for

          Show
          chriskilding Chris Kilding added a comment - - edited Have you had a look at the custom clients feature of the plugin? It's available in the released version, currently behind a beta flag. It allows the plugin to do ListSecrets with multiple custom AWS SDK clients. For example, this would allow you to specify two profiles "staging" and "production" in the ~/.aws/config and credentials files on your Jenkins box, and use both of them in the Secrets Manager ListSecrets call. The provider will then present one big list of credentials from both clients: unclassified: awsCredentialsProvider: beta: clients: - credentialsProvider: profile: profileName: "staging" - credentialsProvider: profile: profileName: "production" You can also set the region and endpointConfiguration per-client if you wish. When custom clients mode is enabled, credentials from the Secrets Manager provider currently use the secret ARN as their ID (rather than the secret name) to ensure there are no collisions between secrets from different accounts. More info in the docs Let me know if this is the kind of thing you're looking for
          Hide
          chriskilding Chris Kilding added a comment -

          Hi again, I've recently enabled GitHub Issues so I'm revisiting outstanding Jira tickets to decide whether to migrate them or close them.

          It would be technically possible to let you specify an AWS access key in the Jenkins config, as opposed to putting it in ~/.aws/credentials.

          However you mentioned dynamically switching the account that Jenkins gets secrets from within a job, potentially switching multiple times within the job.

          This is not something that specifying the access key in the Jenkins config could solve, as that statically authenticates Jenkins to a single account. Just like putting the key in ~/.aws/credentials would do.

          Regrettably I found the multi-accounts beta feature doesn't work because Jenkins doesn't like using an ARN as a credential ID, probably due to some characters in the ARN not being acceptable. As a result I'll need to remove it for now.

          I have lately been thinking that Jenkins needs some kind of namespacing feature, at least for the credentials API, and probably for other things too, so that we can represent resources coming from different cloud accounts within Jenkins. Maybe even allow the namespace to be passed as an implicit parameter to a block of pipeline steps, so that any credentials call within the block will know that it needs to use that namespace when looking up credentials.

          Such a feature would be beyond this credentials provider in scope, it would have to be added to multiple Jenkins API plugins.

          If this is of interest to you then we can open a new ticket to talk about it in GitHub?

          Show
          chriskilding Chris Kilding added a comment - Hi again, I've recently enabled GitHub Issues so I'm revisiting outstanding Jira tickets to decide whether to migrate them or close them. It would be technically possible to let you specify an AWS access key in the Jenkins config, as opposed to putting it in ~/.aws/credentials. However you mentioned dynamically switching the account that Jenkins gets secrets from within a job, potentially switching multiple times within the job. This is not something that specifying the access key in the Jenkins config could solve, as that statically authenticates Jenkins to a single account. Just like putting the key in ~/.aws/credentials would do. Regrettably I found the multi-accounts beta feature doesn't work because Jenkins doesn't like using an ARN as a credential ID, probably due to some characters in the ARN not being acceptable. As a result I'll need to remove it for now. I have lately been thinking that Jenkins needs some kind of namespacing feature, at least for the credentials API, and probably for other things too, so that we can represent resources coming from different cloud accounts within Jenkins. Maybe even allow the namespace to be passed as an implicit parameter to a block of pipeline steps, so that any credentials call within the block will know that it needs to use that namespace when looking up credentials. Such a feature would be beyond this credentials provider in scope, it would have to be added to multiple Jenkins API plugins. If this is of interest to you then we can open a new ticket to talk about it in GitHub?
          Hide
          chriskilding Chris Kilding added a comment -

          I'm switching the issue tracker for this plugin over to Github Issues. I'll close this issue here and then if necessary we can continue on GitHub.

          Show
          chriskilding Chris Kilding added a comment - I'm switching the issue tracker for this plugin over to Github Issues. I'll close this issue here and then if necessary we can continue on GitHub.

            People

            Assignee:
            chriskilding Chris Kilding
            Reporter:
            red888 red der
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: