On 14 July 2014 15:25, martin flehmig <[email protected]> wrote:
> Hi! > > Am 11.07.2014 14:11, schrieb Stephen Connolly: > > and what is the domain specification in each credential domain? > > > > If the credentials are all scope System, then it is a bug in the plugin > > providing the credentials drop down if they show up in a job > configuration > > screen. > Yes, all SSH credentials are in scope "System". > > > If the credential domains have a sufficiently restrictive domain > > specification then the credentials drop down will narrow its selection > as, > > e.g. the SCM URL is progressively completed. > > > > Finally if you install the folders plugin (oh look it's fully [open > source]( > > https://github.com/jenkinsci/cloudbees-folder-plugin/) and [available > from > > the update center]( > > https://wiki.jenkins-ci.org/display/JENKINS/CloudBees+Folders+Plugin)... > it > > only retains the `cloudbees-` prefix because it was the only way we could > > convince the sales guys to let us open source it ;-) ) then you can have > a > > credential store specific to a folder and thus only jobs within the > folder > > have access to the credentials defined in the folder... > > > > So you could have a folder for Project A and a folder for Project B (but > > that only works if the credentials matter to jobs... > Yes, this works as expected and discribed in the manuals. > > > if the credentials > > matter to slaves System scope should have you sorted... and if it doesn't > > please provide a step by step (assume-dealing-with-an-idiot-style) test > > case and I will check if there is a bug) > Okay, here is the step by step test case (minimal example): > > 1) Setup a clean Jenkins > > 2) Install/update credentials > * Credentials Plugin > * SSH Credentials Plugin > * SSH Slaves plugin > * MapDB API Plugin > * SCM API Plugin > * Subversion Plugin > * SSH Credentials Plugin > * Credentials Plugin > * CloudBees Folders Plugin > * Role Strategy Plugin > > 3) Restart Jenkins (in order to make updated plugins available) > > 4) Manage Jenkins: Configure Global Security > * Enable Security > * Access control: Jenkin's own user database > * Authorization: Role-Based Strategy > > 5) Add users: > * userA > * userB > > 6) Manage Jenkins: Manage Roles > * Global Roles: > * admin: Check in everything > * authenticated: > - Overall > Read > - Credentials > Create > - Slave > Create > * Slave Roles: > * projectA-slaveNodeManager > - Pattern: nodeA > - Check in everything > * projectB-slaveNodeManager > - Pattern: nodeB > - Check in everything > > 7) Manage Jenkins: Assign Roles > * Slave Roles: > * userA > projectA-slaveNodeManager > * userB > projectB-slaveNodeManager > > 8) Login as userA and create slave node called nodeA: > * Configure nodeA: > * Launch method: Launch slave agents on Unix machines via SSH > * Host: [email protected] > * Add Credentials: > - Username with password > - Scope: System > - Username: userA > - description: userA@dummNode > * save and log out > > 9) Login as userB and create slave node called nodeB: > * There you can see and use the credentials userA@dummyNode! > Unless you put the nodeA credentials in a credentials domain bound to dummyHost then that is functioning as designed.... it is not possible to restrict credentials further. If you have access to configure one slave you have access to all credentials that are available for connecting slaves. > > > Can you reproduce the failure? > > > Thanks, > martin > > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
