• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • matrix-auth-plugin
    • None

      It would be extremely helpful for the job configuration screen to display the complete list of the permissions that are being inherited when the Inheritance Strategy is set to "Inherit permissions from parent ACL" above the permissions that are specifically set for the job being configured.

          [JENKINS-68099] Display inherited permissions

          Daniel Beck added a comment -

          Not really straightforward. I have to think about this.

          Meanwhile, https://plugins.jenkins.io/security-inspector/ might be an adequate workaround.

          Daniel Beck added a comment - Not really straightforward. I have to think about this. Meanwhile, https://plugins.jenkins.io/security-inspector/ might be an adequate workaround.

          Chris Weiss added a comment - - edited

          The Security Inspector plugin does somewhat what we were hoping for when you select to view by `job`. I was envisioning the output to look something like the below - where the breadcrumb of the folder hierarchy is shown and selecting a specific level on the hierarchy would show the credentials at that level (including, if inherited, any applicable parent credentials).

           

          Chris Weiss added a comment - - edited The Security Inspector plugin does somewhat what we were hoping for when you select to view by `job`. I was envisioning the output to look something like the below - where the breadcrumb of the folder hierarchy is shown and selecting a specific level on the hierarchy would show the credentials at that level (including, if inherited, any applicable parent credentials).  

          Daniel Beck added a comment -

          So you want to be shown permissions that aren't actually inherited at the level you're at? Why would that be useful?

          Daniel Beck added a comment - So you want to be shown permissions that aren't actually inherited at the level you're at? Why would that be useful?

          Chris Weiss added a comment -

          It would be the aggregate of all the permissions at that level. Our problem is that we have a fairly sprawling folder structure with mixes of permissions that are inherited and added along various steps of the tree. It can be a challenge trying to figure out why UserX has Edit access in job /foo/bar/bat/bar1/foo1/bat1 when that access was added at bar1 - it means manually walking the job tree to see where that particular access was defined.

           

           

          Chris Weiss added a comment - It would be the aggregate of all the permissions at that level. Our problem is that we have a fairly sprawling folder structure with mixes of permissions that are inherited and added along various steps of the tree. It can be a challenge trying to figure out why UserX has Edit access in job /foo/bar/bat/bar1/foo1/bat1 when that access was added at bar1 - it means manually walking the job tree to see where that particular access was defined.    

          Daniel Beck added a comment -

          It can be a challenge trying to figure out why UserX has Edit access in job /foo/bar/bat/bar1/foo1/bat1 when that access was added at bar1

          Not a use case I expected from the initial description (it seemed to ask for one table of effective permissions for the current item), now the hierarchy view makes sense.

          What other use cases make sense to cover?

          Daniel Beck added a comment - It can be a challenge trying to figure out why UserX has Edit access in job /foo/bar/bat/bar1/foo1/bat1 when that access was added at bar1 Not a use case I expected from the initial description (it seemed to ask for one table of effective permissions for the current item), now the hierarchy view makes sense. What other use cases make sense to cover?

          Chris Weiss added a comment -

          I could see using it to verify the permissions that will be applied when creating a new job.

          Chris Weiss added a comment - I could see using it to verify the permissions that will be applied when creating a new job.

          James added a comment -

          This would be a nice feature to get a full picture of what permissions are applied by inheritance.

           

          I have the following JCasC and JobDSL working:

          jobs:
          - script: |
              folder("Test") {
                  properties {
                      folderCredentialsProperty {
                          domainCredentials {
                              domainCredentials {
                                  domain {
                                      name("Test creds")
                                      description("Credentials only for Test folder")
                                  }
                                  credentials {
                                      usernamePasswordCredentialsImpl {
                                          scope("GLOBAL")
                                          id("test-git-token")
                                          description("Git token")
                                          username("git")
                                          password("git-password")
                                      }
                                  }
                              }
                          }
                      }
                  }
              }
          - script: |
              folder('Test') {
                  properties {
                      authorizationMatrix {
                          inheritanceStrategy {}
                          permissions([
                              'USER:Job/Read:user1','USER:Job/Cancel:user1','USER:Job/Build:user1',
                              'USER:Job/Read:user2','USER:Job/Cancel:user2','USER:Job/Build:user2',
                          ])
                      }
                  }
              }
          - script: |
              multibranchPipelineJob('Test/test-job') {
                  properties {
                      authorizationMatrix {
                      }
                  }
                  displayName('test-job')
                  branchSources {
                      branchSource {
                          source {
                              git {
                                  id('Test/test-job')
                                  serverName('git-server')
                                  credentialsId('ssh-key')
                                  projectPath('Test/test-job')
                              }
                          }
                      }
                  }
              }

          You can see permissions at the Folder level (ignore the user not found error)

          On the actually job the following only shows up if I add authorizationMatrix{} to the JobDSL

          James added a comment - This would be a nice feature to get a full picture of what permissions are applied by inheritance.   I have the following JCasC and JobDSL working: jobs: - script: |     folder( "Test" ) {         properties {             folderCredentialsProperty {                 domainCredentials {                     domainCredentials {                         domain {                             name( "Test creds" )                             description( "Credentials only for Test folder" )                         }                         credentials {                             usernamePasswordCredentialsImpl {                                 scope( "GLOBAL" )                                 id( "test-git-token" )                                 description( "Git token" )                                 username( "git" )                                 password( "git-password" )                             }                         }                     }                 }             }         }     } - script: |     folder( 'Test' ) {         properties {             authorizationMatrix {                 inheritanceStrategy {}                 permissions([                     'USER:Job/Read:user1' , 'USER:Job/Cancel:user1' , 'USER:Job/Build:user1' ,                     'USER:Job/Read:user2' , 'USER:Job/Cancel:user2' , 'USER:Job/Build:user2' ,                 ])             }         }     } - script: |     multibranchPipelineJob( 'Test/test-job' ) {         properties {             authorizationMatrix {             }         }         displayName( 'test-job' )         branchSources {             branchSource {                 source {                     git {                         id( 'Test/test-job' )                         serverName( 'git-server' )                         credentialsId( 'ssh-key' )                         projectPath( 'Test/test-job' )                     }                 }             }         }     } You can see permissions at the Folder level (ignore the user not found error) On the actually job the following only shows up if I add authorizationMatrix{} to the JobDSL

            danielbeck Daniel Beck
            cweiss Chris Weiss
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: