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
Related
I'm new to Azure AD. However, I observed a weired behaviour in Azure.
After adding / deleting the resource group. The notification says, its success. However, after checking again in few minutes:- (The deleted resources roles are added back into package and the added resources are getting removed as well. This is happening automatically.) I do't have any clue, Anyone faced similar issues? OR, could it be some seetings which is forcing group( sg-ag-rg* group) to stay intact to the access package?
Could anyone please clarify or give some clue? Thanks.
• It might be because they are getting deleted in background and when you check again instantaneously, you would be seeing them as being there itself again. Or else, it might be due to an Azure policy assignment to specific selected users due to which, even after deleting the resource group, the access package assigned to the user is not deleted and is recreated once again since it is a part of Azure AD Identity and Governance.
• I would suggest you to please remove all access package assignments for all the users, groups and applications or sites and their entitlements and then try deleting the access packages and subsequently, the resource group. Thus, in this way, the resource role related to access package will be deleted successfully and will not be recreated even after resource group deletion.
For more information regarding this, you can please refer to the documentation link below: -
https://learn.microsoft.com/en-us/azure/active-directory/governance/entitlement-management-access-package-resources#remove-resource-roles
https://learn.microsoft.com/en-us/azure/active-directory/governance/entitlement-management-access-package-edit#delete-an-access-package
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.
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.
In our organisation we recently moving to git, I have created a group accidentally I would be appreciate if there is a way to delete this group.
In the most recent version (Mar. 2019):
At top bar, click on Groups.
Type part of the name of the desired group or click on Explore Groups. Click on the desired group.
Go to Settings > General
Expand Path, transfer, remove
At the bottom of page you find Remove group. Click on the button and type the name of the group to activate Confirm button. Then click on Confirm to delete the group.
On the recent version (per posting date 11.4.4) navigate to your group's
Settings > General > Advanced > Expand
There you will find the Remove group button.
The group deletion has changed with GitLab 14.8 (February 2022)
Delete groups at the parent group level
In this milestone, we’ve worked on one of the initial steps to reach feature parity between group owners (in any installation base) and administrator-only functionality that exists solely in the administrator panel for self-managed users.
Group owners can now delete a group and its subgroups from the parent group level. Until now, group owners had to go into each individual group to delete them, which was timely and inefficient. Group owners can now view all groups and delete them from a single place.
See Documentation and Issue.
Note: GitLab 15.4 (September 2022), but only the non-free version, comes with:
API support for immediate group deletion
You can now use the API to immediately delete individual subgroups. Prior to this release, you could only delete individual subgroups from group settings in the UI.
See Documentation and Issue.
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.