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

Name fields of AWS Secrets Manager Secrets are not distinct

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Currently, any AWS Secret in Jenkins has the name "AWS Secrets Manager secret." This is not a major issue in the credentials browser or accessing in a pipeline script, as the credential ID is unique – however, in the "Configure System" page, many plugins use the names rather than the ID to choose these secrets from the dropdown (see images)

      The solution that I will experiment with is to source the credential name from the description field attached to the secret in AWS, however, using the ID as the description instead would work well.

       

        Attachments

          Activity

          Hide
          chriskilding Chris Kilding added a comment -

          Ah yes, I think this bug was introduced by accident, since my team defines all its jobs through either JobDSL or Jenkinsfiles (and not through the Web UI - where we would have noticed and caught this bug). It definitely needs fixing.

          Show
          chriskilding Chris Kilding added a comment - Ah yes, I think this bug was introduced by accident, since my team defines all its jobs through either JobDSL or Jenkinsfiles (and not through the Web UI - where we would have noticed and caught this bug). It definitely needs fixing.
          Hide
          ntalbot Nat Talbot added a comment -

          Was this introduced from the multiple-credential-types changes, or is it a separate issue? I had assumed it was a separate issue, but looking at the changes I'd guess it's related to the DescriptorImpl in AwsCredentials.java?

          Show
          ntalbot Nat Talbot added a comment - Was this introduced from the multiple-credential-types changes, or is it a separate issue? I had assumed it was a separate issue, but looking at the changes I'd guess it's related to the DescriptorImpl in AwsCredentials.java?
          Hide
          ntalbot Nat Talbot added a comment -

          Aha, looks like it was introduced by the changes, after re-installing from master.

          Show
          ntalbot Nat Talbot added a comment - Aha, looks like it was introduced by the changes, after re-installing from master.
          Hide
          chriskilding Chris Kilding added a comment -

          I investigated a bit and found the following...

          As long as the `AwsCredentials` type implements `StringCredentials`, the ID is used for the name. But if it extends any of the other credentials types (`StandardUsernamePasswordCredentials` etc), even individually, the fallback text appears instead.

          I initially wondered if this could have been a bug in the credentials type definitions themselves so tried spawning some creds in the local disk-backed creds provider. But the names all worked properly, so the credentials type definitions are fine.

          One interesting thing is that when AWS credentials are shown in the list view, no matter what credentials interface I tell the `AwsCredentials` class to implement instead of `StringCredentials`, it is always presented as 'secret text' (with the blue key icon). So it seems that the `AwsCredentials` objects are always being treated as `StringCredentials`, even when they do not implement that type. And when they don't fit the `StringCredentials` form I guess the default descriptor message is used to fill in the blanks.

          Show
          chriskilding Chris Kilding added a comment - I investigated a bit and found the following... As long as the `AwsCredentials` type implements `StringCredentials`, the ID is used for the name. But if it extends any of the other credentials types (`StandardUsernamePasswordCredentials` etc), even individually, the fallback text appears instead. I initially wondered if this could have been a bug in the credentials type definitions themselves so tried spawning some creds in the local disk-backed creds provider. But the names all worked properly, so the credentials type definitions are fine. One interesting thing is that when AWS credentials are shown in the list view, no matter what credentials interface I tell the `AwsCredentials` class to implement instead of `StringCredentials`, it is always presented as 'secret text' (with the blue key icon). So it seems that the `AwsCredentials` objects are always being treated as `StringCredentials`, even when they do not implement that type. And when they don't fit the `StringCredentials` form I guess the default descriptor message is used to fill in the blanks.
          Hide
          chriskilding Chris Kilding added a comment -

          Fixed on the branch.

          Show
          chriskilding Chris Kilding added a comment - Fixed on the branch.

            People

            Assignee:
            chriskilding Chris Kilding
            Reporter:
            ntalbot Nat Talbot
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: