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 -

            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?

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

            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.

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

            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)?
            Show
            chriskilding Chris Kilding added a comment - 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)?
            Hide
            rittneje Jesse Rittner added a comment -
            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.
            Show
            rittneje Jesse Rittner added a comment - 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. We are currently just using folders from that CloudBees plugin. We are considering switching to their Folders Plus plugin in the near future. See above. Our team has three different deployment environments: dev, QA, and prod. We are not currently using any other credential providers.
            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.

              People

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

                Dates

                • Created:
                  Updated: