I'm using the below security configuration to one of my nodes (user A):
But still, when I'm (user B) doing replay to some job, and change the node('your-node') to user A node, the job still running, although my user is not authorize. I was expecting it will fail with permission. any idea why?
Jenkins version: 2.361.2
Related
Is there a way Jenkins knows how to compare between user (user b) who did replay job to the user who ran the original job (user a)?
You can use the Audit Trail plugin to see the user who did the replay and original job or use the Jenkins REST API to get build information and compare BUILD_USER variable of the replay and original build, the API looks like this: <Jenkins_URL>/job/<Job_Name>/<Build_Number>/api/json
I'm trying to trigger a job from one Jenkins (A) on another one (B). I've installed 2 plugins:
Parameterized Remote Trigger
Build Token Root
My issue is, that I'm able to trigger build on Jenkins (B) using for example curl and token only, which means the Build Token Root plugin is working as expected, but Parameterized Remote Trigger seems to don't respect this.
I probably should mention that I've tried different auth options, Trust All certs, etc.
My Jenkins (A) config:
Logs are the same with and without Build Token Root support enabled.
Logs I'm getting:
I was able to get this working by allowing Anonymous users Overall Read and Job Read access. It appears this is necessary because the Parameterized Remote Trigger plugin attempts to call additional APIs apart from just the /build and /buildWithParameters and those calls are the ones that fail.
It makes sense that, in order to have the default blocking capability, you need to call additional APIs to poll, but even setting blockBuildUntilComplete : false did not fix the issue. Considering that Parameterized Remote Trigger plugin plainly says it "plays well" with the Build Token plugin in its documentation, it really is not an easy feat to make them work together.
In my opinion, using the two together isn't an ideal solution because of the necessity for allowing unauthenticated users to browse your jenkins instance via the ui - I suspect you could (although I haven't tried it) get an API Token for a user with only Overall Read and Job Read access instead of giving all Anonymous Users the rights, but this includes the overhead of managing a user and an API Token, which defeats our primary motivation to use the Build Token plugin in the first place.
I've got an issue with Jenkins 2.6-1.1 running on CentOS v7.2.1511. I am using the Crowd 2 integration plugin v.1.8 and the Matrix Authorization Strategy plugin v.1.3.2 for authentication and authorization, respectively. Security is configured for "Project-based Matrix authorization strategy".
In my Jenkins configuration, I employ two group assignments on the Crowd server: jenkins-administrators and jenkins-users. jenkins-admininstrators has every permission enabled. jenkins-users have permission to:
Overall: Read, RunScripts
Agent: Build, Configure, Connect, Create
Job: Build, Cancel, Configure, Create, Delete, Discover, Read, Workspace
Run: Delete, Update
View: Configure, Create, Read
SCM
jenkins-administrators obviously have all of these permissions enabled as well.
The issue is that, at some point, users who are in both jenkins-administrators and jenkins-users ceased having the ability to configure nodes or create new nodes. What I mean by this is that, when the user clicks on the link to configure a node, or clicks OK on the new node (/computer/node) page, the post goes through, but a page is never returned.
If I remove the user from the jenkins-administrators group, they are able to add and configure nodes as expected.
If I configure the user such that they are in the jenkins-admininstrators group solely, they are unable to login (which seems like it could be related).
I tried modifying the security matrix so that jenkins-administrators and jenkins-users had the same configuration in re: to nodes, but this didn't change anything.
Outside of the slave logs, and the occasional message to /var/log/messages, there doesn't appear to be anything relevant in /var/log/jenkins/jenkins.log.
Any suggestions on how I can configure Jenkins logging to show me information that is more relevant to node configuration and creation, or any suggestions in general on how I might observe the node creation and configuration process?
I want to create a Groovy script using Pipeline plugin in Jenkins handling the security for only some users can enter to the node.
This would be the example:
node('master') {
//code..... more code
}
node('production') {
//more code.....
}
I want to be able that only some users can run succesful the production node without using the input step that ask for only specific users/groups can approve it.
Is there a configuration option where I can configure the security of a specific Node about what users (or group) can execute scripts on it.
Note: I am using only Jenkisn 1.6 (not Cloudbees which it is with more complex security options)
Edited 04/20/2016 reflecting discussions in comment:
Update: Goal: Preventing unauthorized user from executing jobs on a selection of Jenkins node.
Update: The Job Restrictions Plugin referred by luka5z would be a promising fit for the goal, when using it in conjunction with Role Strategy Plugin.
Give Matrix-based security a try with this plugin Role Strategy Plugin. First, you need to set users/anonymous group global role to have a very minimal access. Then you can set slave roles that only allow users to use node name in staring in a pattern e.g QA_Slave*, and only a small group, say admin, have all permissions on all slaves, which implies Production.
Update: Role Strategy Plugin can prevent user from modifying policy applied to node, but would not protect node from running a job it was tagged to. [unauthorized slave assignment in job configuration] where Job Restrictions Plugin would independently apply restrictions on the node level, without go extreme and taking all job configuration access away.
Similar to this question How can we execute Jenkins job using other user credential
I have users who will login to Jenkins using active-directory credentials, and then as part of the job use publish-over-cifs, which must use the same domain credentials they supplied when logging in.
This would require that Jenkins retains the password in memory in order to provide it to the cifs plugin.
How should I do this?
I've added a Jenkins Issue https://issues.jenkins-ci.org/browse/JENKINS-22561?focusedCommentId=198490#comment-198490 sponsored for $25 https://freedomsponsors.org/core/issue/483/publish-over-cifs-should-be-able-to-use-jenkins-session-credentials-including-domain-when-jenkins-active-directory-authentication-is-used?alert=SPONSOR#
I am sorry, I don't know how to answer your question, but here is a completely off-the-wall hypothetical solution.
The AD user, on their own machine, is already logged in and can use the AD shares/SMB with their logged in credentials.
Design a job that asks the user for the IP address of their machine. Then have the job spawn a Jenkins Slave on that machine, and execute the job on that Slave, so that it inherently gets access to AD.
This answer probably deserves a downvote