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

Allow configuration per folder rather than globally

    Details

    • Similar Issues:

      Description

      The fact that this plugin can only be configured at the global level is a deal-breaker for us. It would be better if this plugin supported configuring it per folder, so that different folders can be scoped to have access to different secrets. (For example, our production secrets must not be accessible to non-production build jobs.)

        Attachments

          Issue Links

            Activity

            Hide
            chriskilding Chris Kilding added a comment - - edited

            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.

            Show
            chriskilding Chris Kilding added a comment - - edited 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: 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. 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.
            Hide
            chriskilding Chris Kilding added a comment - - edited

            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).

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

            Show
            chriskilding Chris Kilding added a comment - - edited 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). Jesse Rittner I'd appreciate your feedback on GitHub PR #25 to indicate if the cross-account feature design will work for your setup.
            Hide
            rittneje Jesse Rittner added a comment -

            Chris Kilding 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?

            Show
            rittneje Jesse Rittner added a comment - Chris Kilding 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?
            Hide
            chriskilding Chris Kilding added a comment -

            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.

            Show
            chriskilding Chris Kilding added a comment - 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.
            Hide
            chriskilding Chris Kilding added a comment - - edited

            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.

            Show
            chriskilding Chris Kilding added a comment - - edited 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.

              People

              • Assignee:
                chriskilding Chris Kilding
                Reporter:
                rittneje Jesse Rittner
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: