Azure Devops permission for some repositories - azure

We have an Azure Devops Project with several repositories.
However we only want to give access to a couple of repos to another team.
I've setup a group called Outsource (oddly it doesn't show under Project Settings > General > Teams) and within the Project Settings > Repos > Repositories section i've given the group permissions.
However they can't access theses repos from My Org > Repos (red icon).
Also they can't clone the repos either.
The one user in the 'Outsource' group is setup as a basic user.
Can anyone tell if I'm missing a setting? It doesn't seem like providing permission against a repo does anything?
I also gave them access to a different project and they can access that fine.

Stakeholder user cannot access private project repo.
The permission group Outsource is collection level group, we recommend that you open the project settings and create a project level permission group and add these users.
Configure permission
Open project settings-> Repositories->click one repo-> select the repositories which you want to give access to another team->add the permission group and set the permission Read to Allow. Then the group users can access these repositories.
Select the repositories which you do not want to give access to another team->add the permission group and set the permission Read to Deny. Then the group users cannot access these repositories.

Related

Error creating new repository (PERMISSION_DENIED)

I have a problem creating a new repository in Cloud Source Repository (console or gcloud).
In the gcloud case, when I run the following command using either an user account with roles/owner or a service account with roles/source.admin:
gcloud source repos create new-repo
I get the following error:
ERROR: (gcloud.source.repos.create) ResponseError:
status=[PERMISSION_DENIED], code=[403], message=[User [xxx#xxx] does
not have permission to access projects instance [PROJECT_ID] (or it
may not exist): The caller does not have permission].
The project currently has no repositories associated to it. I was able to create one earlier (through the console) which I then deleted before using. I have been unable to create any subsequent repositories since.
Would love to hear some suggestions if anyone else has faced a similar issue.
As you mentioned to have the proper roles on the account this issue is due to not having a billing account linked to the project.
The API methods used to create a repository require the billing on the project to be enabled so to solve it if this is the issue you can perform the following steps
Go to https://console.cloud.google.com/billing
Select the project where you want the repository to reside
Click on Link a Billing Account
A Popup message will show, over there click on Create Billing Account
Follow the wizard

Azure DevOps Stage Permissions

I have created a release pipeline with multiple stages. Now I would like on users form the Release Manager group or Project Administrators group to be able to deploy some of these stages.
I have tried to denied "Manage Deployments" to the other groups but it seems as soon as Contributors lose this, no one, not even members of the above groups with the permission set to Allow can deploy the stage anymore. BTW, members of the allowed groups are also members of Contributors.
I tried both just updating the permission and removing Inherited permissions and then removing the permission for those groups and still no go.
Is there any way to remove this permission from Contributors but sill allow members of Contributors + Release Manager + Project Managers to deploy?
Thank you
Is there any way to remove this permission from Contributors but sill allow members of Contributors + Release Manager + Project Managers to deploy?
I could reproduce the scene you mentioned. It seems that the permissions of the Contributors group will override the permissions of the other two groups.
To solve this issue, you could set the Manage Deployments as Not Set instead of Deny. At the same time, you need the disable Inheritance option.
Note: If you set Not Set, people in the contributor group cannot deploy, but if some of them are in other groups with this permission, they will inherit the permissions from other groups

Azure DevOps: policy for branch creation

We want only some people to be able to create 'release/*' branch in Azure DevOps cloud(?) repo.
Unfortunately, I couldn’t find this option in UI.
I also couldn’t find it here
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops
and here
https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-permissions?view=azure-devops
I tried to implement it with REST API but my attempts were unsuccessful.
I also didn’t find any extension which could help me with this.
I'm still looking for a solution.
There is not option in the UI to set the create branch permission for branches.
However, you can achieve this by runing tf git permission commands in Developer Command Prompt for Visual Studio to deny the permission to create branches under releases. See below example:
Below command will block the users in Contributors group creating branches under releases
tf git permission /deny:CreateBranch /group:[MyProject]\Contributors /collection:https://dev.azure.com/MyOrganiza/ /teamproject:MyProject /repository:myRepo /branch:releases
Check Git Permission Command for more information.

Gitlab master access level

I have a Gitlab group (testgroup) also I have the project (testproject). Now the testproject is in the testgroup.
What would happen if I added A group (testgroup) master as a developer in the inside of the project?
Would they able to accept the merge request for the particular project?
How could I add the group master as a developer in the same group's project?
Someone who is declared a group master is not a project Master, even if that project is in the group
See Group permission: he or she only has the additional privilege of creating projects in the group.

Jenkins Slave 403 although Anonymous Slave connect has been enabled

We are using a Jenkins Master and Slave (both Linux) type setup. Recently upgraded to LTS version and for some reason Slaves connects to Master only when Anonymous is given Admin privileges.
I have read the posts about providing Anonymous slave connect privileges but I receive a 403 request forbidden error when I try that.
The only way around for this is to provide Anonymous Admin privileges (which is risky) save it and then go back to Manage Jenkins > Configure Security > Remove Anonymous Admin > Add Slave connect privileges.
The issue in doing this workaround is, I get the same 403 error when slave restarts until I give Anonymous admin privileges.
I have tried laying down a new slave.jar that didn’t help.
We are using a LDAP Bind account, is there an easy fix to this 403 issue without having to enter the bind password again (which we recently did after the Jenkins upgrade)
Nothing like an answer 1.5 years later but I just ran across this!
The way I handled this is with the Role-Based Strategy plugin.
Summary
The basics are:
Add and enable the Role-Based Strategy plugin
Create a global group swarmclient
Grant the swarmclient group the slave privileges only
I currently allow the Anonymous group to be in the swarmclient group.
In the future I will probably deny swarmclient privileges for the Anonymous group and will instead create accounts in the swarmclient group.
Details
In Manage Jenkins > Configure Global Security > Authorization, enable Role-Based strategy.
In Manage Jenkins > Manage Roles > Manage and Define Roles I added "swarmclient" to the global roles. Give this group Create permissions in the slave section of the global settings:
In newer versions of Jenkins the term "Slave" is replaced by "Agents"
Then in Manage Jenkins > Manage Roles > Assign Roles you add the Anonymous group to the swarmclient group:
And finally, as mentioned above, if you want some restrictions on the machines that can connect as a swarm client, just:
create user(s) for the swarm
add them to the swarmclient group
remove swarmclient permissions (on the Assign Roles) page from the Anonymous group.

Resources