The plugin can access more secrets using secondary IAM roles.

The most common use case is to access secrets in other accounts using cross-account roles. In this setup, Jenkins accesses secrets in its own account using its (implicit) primary role, and is assigned a secondary role for each other account that it should read secrets from.

Secrets in different accounts may have the same name. To allow them to co-exist within Jenkins, credentials from primary and secondary roles use different secret attributes for their IDs:

Role	Credential ID
Primary	Secret Name
Secondary	Secret ARN

Setup

For each secondary role:

1. Create the role and associated policies in AWS.
2. Test that Jenkins can assume the role and retrieve secrets.
3. Add the role's ARN to the list below.

Considerations

Do not add more roles than necessary. Each additional role necessitates another set of HTTP requests to retrieve secrets. This increases the time to populate the credential list. It also increases the risk of service degradation, as any of those requests could fail.