chriskilding Thanks so much for looking into this! Can you clarify what information you are looking for? At a high level, this is what we'd like:

1. Create a folder-scoped secret for the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. These could either be two string credentials, or a single AWS credentials (https://github.com/jenkinsci/aws-credentials-plugin/blob/master/src/main/java/com/cloudbees/jenkins/plugins/awscredentials/AWSCredentialsImpl.java).
2. Configure the aws-secrets-manager-credentials-provider-plugin for that folder. We can configure it with the settings for our specific account. It should use the folder-scoped credentials from (1) to authenticate. Bonus points if we can pull settings from the folder properties plugins. https://wiki.jenkins.io/display/JENKINS/Folder+Properties+Plugin and/or https://docs.cloudbees.com/docs/cloudbees-core/latest/cloud-secure-guide/folders-plus

Also, if possible we would prefer to be able to configure all of this via Job DSL, not the GUI. https://wiki.jenkins.io/display/JENKINS/Job+DSL+Plugin

I believe the JENKINS-60897 proposal can do what you ultimately are trying to achieve (having some credentials restricted to jobs in folder A, some restricted to jobs in folder B, some restricted to jobs in folders A and B, and some global credentials with no folder restrictions).

But there is a fundamental constraint in the way: a plugin has only one instance in Jenkins. You couldn't run multiple instances of a plugin (e.g. to apply different configurations) on the same Jenkins server.

So under the proposal, you'd achieve it like this instead:

• Install credential provider plugin.
• Install folders plugin.
• Configure the credentials access control layer (ACL) on the folders plugin. 

Example:

If I have 4 secrets in Secrets Manager that I want to use in Jenkins like this:

• foo (visible to jobs in folders A and B)
• bar (visible to jobs in folder A)
• baz (visible to jobs in folder B)
• qux (global, visible to all jobs)

I would configure the ACL like this in JCasC (I suppose you could also use Job DSL or the GUI):

folders:
  a:
    someUnrelatedProperty: 'hello'
    credentials:
    - 'foo'
    - 'bar'
  b:
    someUnrelatedProperty: 'world'
    credentials:
    - 'foo'
    - 'baz'

(The implication in this particular design is that if you access a credential like qux which has no folder restrictions, it is treated as global.)

Does that sound like what you're after?

We have different accounts for dev vs. QA vs. production. If we can only configure the plugin once globally, that implies we would actually need a separate Jenkins installation for each account, which we definitely do not want to do.

Could you let me know a bit more about your Jenkins setup?

• Is it On premises / hosted in AWS / hosted in another cloud provider?
• Are you using plain folders, or something else that's folder-like e.g. GitHub organization folders?
• Is this Jenkins for one team in your organization with 3 different deployment environments (dev, QA, prod)? Or do multiple teams use it?
• What other plugins do you use which interact with AWS services?
• Which credential providers are you using (apart from the folders plugin, and potentially the Secrets Manager one)?

1. Our Jenkins master is currently on premise with some Azure agents, and is shared with the rest of the organization. We plan to get a team-specific Jenkins installation in the near future, likely hosted on AWS. We were not planning to have multiple installations for our team. We also have a single on-premise Bitbucket server that is shared with the rest of the organization; builds can also be triggered from Bitbucket via a webhook to Jenkins.
2. We are currently just using folders from that CloudBees plugin. We are considering switching to their Folders Plus plugin in the near future.
3. See above. Our team has three different deployment environments: dev, QA, and prod.
4. We are not currently using any other credential providers.

Since your environments are deployed as separate AWS accounts, but you've got only one (environment-independent) Jenkins, it sounds like your intended setup is that Jenkins will run in a shared AWS tools account (not dev, QA, or prod).

The options I can see are something like the following:

1. Put the secrets for each environment in the tooling account. Use the JEP-225 folder-based credentials ACL to restrict jobs so they can only access the right credentials.
2. Store the secrets in their respective environment accounts. We implement JENKINS-59670 (cross-account secret retrieval) so the plugin can fetch secrets from multiple accounts. You give Jenkins IAM cross-account roles so it can call Secrets Manager in those accounts (this is far preferable to supplying 3 access key pairs). Then use the JEP-225 folder-based credentials ACL as in solution 1.

Option 2 is considerably more work, and also increases the number of HTTP requests (and therefore lag, and the possibility for network failures) to list secrets.

But in both cases, the JEP-225 credentials ACL should do what you're asking for.

Closing in favour of a combination of JENKINS-60897 for authZ (add a notion of folders and credentials to the Jenkins access control plugins) and JENKINS-59670 for authN (support multi-account credentials lookup).

rittneje I'd appreciate your feedback on GitHub PR #25 to indicate if the cross-account feature design will work for your setup.

chriskilding I'm not terribly familiar with cross-account credentials, but I have some concerns. What specifically will stop a malicious developer from accessing the production secrets from their feature branch job and printing them out?

Also, I noticed a comment that says "The secret name must be unique across all AWS accounts that Jenkins uses." We require that secret names be identical across the three accounts to maintain consistency.

To clarify, we are not interested in pulling secrets from multiple accounts within a given multibranch pipeline. Rather, each pipeline should only have access to one of the three accounts.

it sounds like your intended setup is that Jenkins will run in a shared AWS tools account

Can you clarify what you mean by this?

How secret names are treated is still up for discussion, at the moment the draft implementation rejects them, but we could potentially support a namespacing feature for this. Eg your Jenkins job would ask for credential ID "<aws-account-id>/<secret-name>" and it would be fetched from the relevant account. This would allow the secret names in each AWS account to be identical. But it leaks an implementation detail - the AWS account ID - into the Jenkins job definition, which is not ideal for credential portability.

When I say Jenkins running in a shared tools account, basically this is a pattern where you have a number of environment-specific accounts (staging, prod) and you want a single Jenkins to manage them. It's not appropriate for that Jenkins to run in any of the environment-specific accounts, because by definition it exists outside those environments to manage them. As a result it is often put in an environment-independent account (sometimes called 'tools') with any other shared infrastructure (e.g. Artifactory), and given cross-account access to manage the relevant AWS resources in each environment. Even if a particular job only gets secrets from, say, the production account, under the hood Jenkins would make cross-account requests to get them. When you said you want to have a single Jenkins managing all three environments, I assumed you had a setup like this in mind.

Regarding the question of access control... a new approach has just come up, which might be more appropriate for your use case.

This approach would involve defining credentials for the folders plugin in JCasC YAML - basically what you have already done with the folders plugin, but codified in YAML. You would interpolate the actual values of those credentials using JCasC interpolation key syntax. The upcoming SecretSource support in the AWS secrets manager credentials provider (JENKINS-61291) would then resolve the values from Secrets Manager, and hand them back to JCasC, which would save them into the on-disk copy of those credentials.

JCasC consults its interpolation sources each time it runs, which should ensure that your credentials stay up to date on a frequency of however often you run JCasC.

As far as your jobs are concerned, the credentials will still come from the folders plugin like they do today. So the folders plugin would still be responsible for access control.