I use jenkins project-based matrix security.
I have this folder structure (jenkins folders):
folder1/subfolder1A/jobA1
folder1/subfolder1A/jobA2
folder1/subfolder1B/jobB
folder2/subfolder2C/jobC
I can't seem to find a way to give access to a particular user only to subfolder1A or to jobA2 etc.
I tried almost every combination of permissions, the only one that works requires me to add the job readpermission to the user for the root folder1. The permission is inherited and they can now see everything in subfolder1A and subfolder1B etc.
If i don't do that, they see nothing. But If I do that, they have access to all subfolders of folder1 and all their jobs (with read permissions).
Do you know any configuration that would allow a user to access only subfolderA or jobA1 ?
I use the latest jenkins 2.x (2.13 at the time of writing, I'll update to 2.14 possibly today)
I know its too late to answer your question however this might be helpful for others.
You can give access up to one level deep to sub folders using Role Based Access Control plugin. In your case, assume if you want to grant an access to subfolder1A and restrict all other sub-folders then you can create Project Role and use following pattern:
folder1(/subfolder1A.*)?
Suppose, you want to provide access to both subfolder1A and subfolder1B and restrict other sub-folders, then use following pattern:
folder1(/subfolder1A.*|/subfolder1B.*)?
This will allow you to control nested folders up to one level.
Hope this will be useful.
Related
I need to review all source code permissions on a particular folder structure. I have gone through the apis and can't find what I need or haven't figured out how to use them correctly yet.
I have also tried the tfssecurity command but, can't figure out how to make it look at just a specific team project.
I am using Azure DevOps Server 2020 and the source is in TFVC.
This is part of a source control audit and I need to produce a report of what permissions users have on a folder in source.
I have tried the following apis: https://learn.microsoft.com/en-us/rest/api/azure/devops/security/?view=azure-devops-server-rest-6.0
Along with the tfssecurity command.
None are producing the results I need.
Found the APIs needed to do this.
Use this one to get all of the namespaces and find the ones that you want to get the security data for.
https://{instance}/{collection}/_apis/securitynamespaces
After that call this API to get the ACLs for that namespace.
https://{instance}/{collection}/_apis/accesscontrollists/{securityNamespaceId}?alwaysAllowAdministrators=True
Once you get all of the ACLs for the namespace, you can then look at each ACE to find out the permissions.
https://{instance}/{collection}/_apis/identities?descriptors={descriptors}&queryMembership=expandedDown
New to gerrit and administration part of access control. We have a couple of gerrit repos and groups. One repo is secret and is visible only to members of a certain group. Cannot wrap my head around exactly what settings or access settings that makes this possible.
It is not the project options state setting “hidden” that I’m looking for. Since the secret repo state is “active” but not showing up on the list and not accessible by other groups. Do I configure the repo I want to make secret in the project.config file or in the access inheritance that is inherited from “All-Projects”? What do I need to configure then? Like: refs/* READ “Allow = Secret Group”? Would this make the repo secret, not showing up in the repo list and only accessible by “Secret Group”? Tried READ DENY to other groups but still showing up. v.2.16.8
You're right:
refs/* READ ALLOW => grant project list permission
refs/* READ DENY => deny project list permission
But...
A project is considered visible if any ref is visible for that user, so check if there's an explicit READ ALLOW on refs/meta/dashboard or any other ref.
See here more details about this.
I have configured Jenkins on centos 7.
Being administrator, I have created few users and gave them permissions to their projects like: build, read etc.
I have used a Project-based Matrix Authorization Strategy. Its working but I'm facing the following problem:
If any user clicks on people information (button on left is dashboard) then any user can view all the other users ids, name etc. I want to block this from happening and I can't find a solution to this problem.
Can it be a configuration problem?
Here is one solution using the Role Strategy plugin.
I'm using this plugin for our Jenkins server and it's really useful to define permissions.
On my staging Jenkins, I've create 2 users:
A full admin
A viewer
I've created 2 roles with the plugin:
Next, I assign the roles to the relevant users:
The viewer role only have a global read access + build on the jobs.
If I open a session with the admin one, I can see all the people:
With the viewer user, I don't see anything:
UPDATE:
If you want to assign some permissions on a specific project, you can create project roles (in the Manage Roles section):
You can filter the projects with a regular expression:
job(.*)postcommit
Next, in the Assign Roles section, you just have to assign the relevant project role to the relevant user.
I hope it helps :)
I am using Folder plugin and AD groups to control access to folder. This morning a team can't access their project anymore and later I found the AD group assignment in Assign Roles has been changed to wrong groups. Is there a way to find out which id did it? We only have a few admin ids.
Jenkins does not appear to keep an audit trail by default, as stated in this post on cloudbees.com, the folks that develop Jenkins.
The relevant lines:
Many Jenkins users look for a recommend a strategy for keeping an audit trail. This article is supposed to be a gap filler until more comprehensive compliance capabilities in JE/JOC are developed.
There are two open source plugins that enable you to track “WHO did WHAT?” in Jenkins:
...
The first plugin listed is Audit Trail Plugin which looks to provide exactly what you are seeking.
The description from the plugins page:
Keep a log of who performed particular Jenkins operations, such as configuring jobs.
This plugin adds an Audit Trail section in the main Jenkins configuration page. Here you can configure log location and settings (file size and number of rotating log files), and a URI pattern for requests to be logged. The default options select most actions with significant effect such as creating/configuring/deleting jobs and views or delete/save-forever/start a build. The log is written to disk as configured and recent entries can also be viewed in the Manage / System Log section.
I spent a few minutes looking through Jenkins various xml and log files, but could not find a log that contained something useful (username and/or timestamp). In this case it seems user auditing isn't built into Jenkins as of yet. Unfortunately it appears that you might not be able to determine who made those changes after the fact.
I am creating an msi-package of a Windows service using Wix. I want to run the service under a regular user account without administrative priviliges. For better security I want to put the files of the service in the personal user folders (such as AppData\Local\Programs\CompanyName... for binaries and AppData\Local\CompanyName... for config and data files) with the appropriate file access permissions for the user. I imagine the following scenario:
Start the msi in the per-machine context.
During the client stage of the installation ask for the user name and password.
During the server stage of the installation:
a) create the user
b) change to its context and install the program files to ProgramFilesFolder and the data files to LocalAppDataFolder
c) change back to the admin context and install and configure the service to be run under the user account
I am stuck at the step 3 b) as from what I've learned I can't change the installation context after switching to the server side of the installation. Please could you advice me on how I could achive my goal described in the first lines. In particular if I have to copy files to another user's personal folders, what would be the most reliable way to get their paths? Or maybe I am wrong and installing a service into a personal user folder is bad practice at all?
I am aware of the presence of the built-in Local Service account but would like to narrow the service context even more.
The local appdata folder is the problem. If you create a user account the user folders aren't created until the user does an interactive login, and even then in some environments it may be redirected via policy. I am unaware of any reason that local data is better (in a security sense) then the ProgramFiles folder, which is write-restricted to administrators. I'd just install the service binaries to ProgramFiles. In the UI you can collect credentials and use them when the service is installed. A problem with using external credentials is that things like Repair and sometimes patching will fail unless you have the credentials available, having saved them somewhere safe, because otherwise the property values you use will be empty on repair. If localservice works then use it.
It normally doesn't matter what privileges a service has because it usually knows what it's doing. It's only an issue if it calls unknown external code that may try to do something bad, or if it gets asked to do random things such as "run this program" or "copy this file" without doing any internal validation or having a whitelist of what it's allowed to do. So it might be useful to know if there's a specific problem you're trying to address or just following good practices.
I don't think you're being overcautious, service isolation is definitely a good goal. If you can require Win7/2008R2 or later, then you can run the service under a virtual account. There is no password required for virtual accounts, and they don't have the ability to completely wreck the machine like SYSTEM does. You should be able to use it like this:
<ServiceInstall Account="NT SERVICE\$(var.ServiceName)" Name="$(var.ServiceName)".../>
It's actually better for the service executables to be in Program Files, that way the service can't modify its own exe.