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?
Related
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
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'm struggling with duplicated users in my Jenkins and Not sending mail to unregistered user ... problem.
I installed the plugin as per this answer but cannot configure it properly by reading the plugin documentation.
My jenkins collects data from Active Directory and some users have duplicated entry, e.g.:
john.doe, john.doe#mycompany.com -> duplicated user which is detected by Jenkins
doej, john.doe#mycompany.com -> correct user which is used when logging in
Jenkins after collecting responsible people from git changes in job ends with
Not sending mail to unregistered user john.doe#mycompany.com
I tried adding additional identity to user doej by setting:
Identity: john.doe#mycompany.com
Realm: <empty>
but it doesn't work.
How should I configure correctly the Additional Identities Plugin?
Seems it's not possible to configure the additional identity plugin in Jenkins for merge the duplicate user
As Jenkins is missing a way to ensure users unicity(unique) since they are created from various sources: authentication method (LDAP in my case), code commits (Subversion, Mercurial, Git, ...).
Depending on the way the user is retrieved by Jenkins (from a commit on a given SCM or its authentication), multiple identities are created for the same real user.
As a consequence, some features are not fully or badly working (login, notifications, user's builds, continuous integration game, ...) and configuration of users is a pain as it must be done multiple times for each real user.
Still the required features are:
a merging features. Allow to merge multiple Jenkins users into a single account.
a user pattern per SCM. Allow to choose how to extract a username from a commit for each SCM and how to optionally match existing one instead of creating a new user.
an id pattern per notification type. Allow to define how to generate the default id used for notification from the user data (from his jenkins id, his name, his scm id, ...): for instance, his mail or his jabber id, ...
Reference: [JENKINS-10258] Allow users unicity - Jenkins Jira
Solution is Jenkins 1.480 but this is still in Vulnerabilities state and have bug as well.
Jenkins 1.480 introduces an extension point to resolve jenkins user "canonical" ID when searching for user in Database by id or full name. This plugin uses this extension point to let user configure external identities as user properties.
You can reach out to Jenkins community or Support team to know the status or when they will final release
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.
I want a block some jobs for a user level for example I have 3 jobs:
Job1 (All the register user can execute this).
Job2 (Only some user can execute this)
Job3 (All the register user can execute this).
Set the Global Security (http://<your_server>/configureSecurity/?) to the configuration that matches most jobs (enable Job Build) and then enable Project-based security for the other jobs (via the jon configuration) and set up as required by disabling Job Build.
Enter the user name in User/group to add: and then configure as required. In this case I've limited control to two users
You need to use Project-based Matrix Authorization Strategy to achieve this. Hudson/Jenkin >> Manage Hudson >> Configre Security >> Authorization, and select Project-based Matrix Authorization Strategy. Now in the configuration page of each job you will have an option Enable job-based security. You can give access permissions for the users here.
This works for me : Role Strategy Plugin
But you need understand it and its official documentation is poor, so go to :
https://stackoverflow.com/a/38516162/3957754
The below link provides the clear guideline to grant/restrict the access to Jenkins Jobs.
http://www.kblearningacademy.com/configure-role-strategy-plugin-in-jenkins/
Its very useful & am able to do the same.