I am looking for a plugin that allows for a View level security. For example I had an AD group I wish to assign to have modification/Execute permissions to ALL jobs under a specific View.
I understand that Views are just filters on the main page of Jenkins but with the quantity of plugins out there I needed to ask.
The Role Strategy Plugin worked wonders for my organization.
https://plugins.jenkins.io/role-strategy/
You cannot control access at view levels but, you can play around with folder plugin to get the desired level of access
Related
Currently, Jenkins add as a user any known user of Jenkins plus any user mentioned in a commit message.
This effectively means that if you are managing several projects in Jenkins instance and each project with tenths of developers then it is really hard to maintain.
Another side effect is that JENKINS_HOME/users are populated with one xml for each of these users, so Jenkins becomes somehow unmanageable. Not the end of the world, that's true, but at the same time you start seeing users from outside of team/organization.
So, is there any way to disable this behaviour?
Thak you so much.
We have 'try' build jobs that developers can initiate with parameterized variables to point to a particular branch for pulling the code and trial running the build in jenkins. Is there a way I can customize a custom personal view showing only the builds that I have started?
The custom way
I think there's a way to customize a personal view by coding / modifying your Jenkins installation, jan-molak worked on that feature here.
You can check the commits and maybe implement something by your own, especially this and this.
The plugin
Take a look on View Job Filter If you configure it, there are options which seems to acomplish what you want:
Logged-in User Relevance Filter: This adds/removes jobs based on their
relevance to the logged in user. For example: matching jobs that were
started by the user, or where the user committed changes to the source
code of the job; matching jobs with a name that contains the user’s
name or login id.
In order to prove that a team is not seeing another team jobs or folders I need to come up with a measurable solution that validate that.How can I test that each team member don't see each other jobs? Because using the UI to see and comparing with my eyes becomes really difficult with multiple of groups or users for instance.
I am using Jenkins Project-based matrix plugin and latest Jenkins.
The best way to do this is by creating a test user. In case you are using AD or Jenkins own user database, try assigning the same permissions to what you have given for team. This way you will know it for sure.
If there are any such security issues chances, Jenkins will raise a notification highlighting the security issue with that of plugin. Hope this solves the issue.
I am new to jenkins and facing 2 issues.
Trying to restric some users to view only specific tabs. For example
if we have All, Dev1, Dev2 and Dev3 tabs I want a specific user to access only Dev1 and Dev2
tabs and they should not be seeing All and Dev3 tab. Is this possible in Jenkins
What ever jobs I add to Dev1, it is showing in All tabs as well. Can we restrict a job to appear only in Dev1 tab. Thanks
I suggest you start by reading the standard security setup page to understand how to enable authentication.
For authorization controls the matrix based authorization is pretty good, but the Role strategy plugin offers more detailed user controls.
I've been reading some feature request-style threads in Atlassian's own JIRA install on how to disable (not remove) users in JIRA, and their suggested solution involves a series of UI actions. For the number of users that our organization supports, this needs to be automated with the rest of our employee account provisioning logic.
I've been looking in the JIRA database and found the membershipbase table, but simply removing records from here WHERE USER_NAME="$username" doesn't seem to have a completely successful outcome. When I go to the User Browser in the Administration section and look up that user, groups still appear for the user.
Does anyone have any experience with this that could point me in the right direction on any other tables I need to modify?
Thanks in advance,
-aj
Maybe you should take a look at Atlassian's Crowd. Even if you don't use SSO, it may help you to integrate with your existing infrastructure for handling authentication and authorization (i.e. groups) centrally. It also provides an administrative frontend that is designed for the corresponding tasks.
You could have a look at the EditUserGroups.setGroupsToLeave() method. As far as I remember, users need to be in the jira-users group to log in. So, if you remove this group from the user, it may be effectively what you need (not delete but deactive user acount).
If this does not help, I'd look into the source code of JIRA (which is available for all types of licenses afaik) to see which tables are modified by the above method.