I need to give someone access to create work items ONLY. They are a 'stakeholder' user. Currently I cannot restrict them from seeing Variable groups OR Task Groups. I cannot see any deny permmisions and the person is in no other groups. I added them to an organization group with DENY permissions in all 4 Pipelines permissions. Still the user can see them
I added them to an organization group with DENY permissions in all 4
Pipelines permissions. Still the user can see them
That's caused by that the permission listed here used to restrict the build view, such as build definition and etc. But, Variable group and Tasks group does not belong to build, they just be linked/called into the build. Set the View build resources as deny could not restrict these objects' permission. For example, Azure Key Vault's view permission could not be restricted by deny the permission of build. It just can be changed in Azure portal.
These function( such as variable group, task group, key vault and etc) which be linked/called into build called object. To modify its permission, you must go objects' security page to change it.
Since what you are focusing is Variable group and Task group, unfortunately, viewing these objects belong the basic permission of Stackholder and could not be restricted in security configuration.
As you can see that there's no permission to restrict View. So, restrict stackhokders view it could not be achieve.
For security, I think you can change their level as Project reader to restrict them do change to them.
Related
Any idea what ACE entry (path, privilege, permission) I should add for a specific group to be able to see (read only) the list of ALL/any active workflow instances?
The list of active instances is under this url
http://xxxx:4502/libs/cq/workflow/admin/console/content/instances.html
I added a jcr:read allow permission on the following paths /etc/workflow/instances, /var/workflow/instances for my group but I still can't see the list of active workflow instances.
You can't make it work by manipulating ACEs.
The AEM Workflow Engine supports a notion of a 'superuser' which can access all workflows, started by any user. Regular users can only see the instances they started.
The list of workflow superusers is controlled by com.adobe.granite.workflow.core.WorkflowSessionFactory
You can define a custom group and add it to this list. Then, providing that the user has read permissions on workflow models and instances, and is a member of a supergroup, they should see all the workflows.
I want to automatize creating users and adding permissisons. Is it possible in grafana, to dynamicaly adds permission to user based on AD group?
Lets say user inputs his data including AD group he is in, and the app will create folder, and sets read/edit permissions only to users that are in AD group (that can be any group )?
I know you can set viewer/editor/admin roles to people based on AD group in config file, but is it possible to do so dynamicaly, with their http api?
You can set permissions for folders and permissions for dashboards using the Grafana HTTP API:
Folder Permissions API
Dashboard Permissions API
The logic, what permission should be set for which user, needs to be determined in your code (e.g. based on the user input you mentioned) before making the request.
I am trying to authenticate with a specific user that has access to pull down a package from a specific Azure Artifact Feed View using a Release Pipeline (which doesn't have the option of being fully YML) in Azure.
My workflow is to allow certain packages to be available via the #rc feed view and not always pull the latest package from the #local feed view since the #local feed view can have multiple packages that are dev builds which aren't ready for RC. I'm attempting to authenticate using an NPM Authenticate task but that doesn't give me the option to specify account details of a user that has isolated access to the #rc feed view.
I'm also not sure which user is actually being authenticated in the pipeline when that Release Pipeline task is run and according to the docs, it's the build user which isn't too clear.
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/package/npm-authenticate?view=azure-devops
I'm also not sure which user is actually being authenticated in the pipeline when that Release Pipeline task is run and according to the docs, it's the build user which isn't too clear.
The project build service account is actually being authenticated in the pipeline when that Release Pipeline task is run by default. You could get it from the Feed settings:
For you case, you could create a service connection with NPM Authenticate task for that specific user with Username/Password or PAT:
And specify that specific user in the option Specific people when you create/edit the RC view：
Note: There are two important concepts to keep in mind:
If a user have permission to a specific view, and even if they don't have permission to the feed, they will still be able to access and download packages through that view. If you want to completely hide your packages, you must restrict both feeds and views permissions. To restrict access to your feed, simply select a user or group from the permission table in your Feed Settings and select Delete. You can restrict access to a view by changing its visibility to specific people.
views inherit their permissions from their parent feed. Setting view
permissions to Specific people without specifying users or groups
will cause the view permissions to default back to their parent feed
permissions.
Please check this document for some more details.
I have checked the docs from Microsoft for AzureDevops and I understand how to manage permissions for a branch.
What I would like to know is if a user is automatically added with Edit Policies permission to Allow as he creates the branch (assuming a normal user not admin, and he's not inheriting this permission) ?
If the answer to the above question is yes, then is there any case when a second user could be added to the list of branch permissions automatically ? without an administrator adding it explicitly ? I couldn't find this in the docs anywhere.
*picture from msdn
Yes, for each branch's permission setting, you could directly manage that user's or create a group then add that consultancy in the group, manage the group's permission.
In other words, without adding it explicitly, the user B could also be added to a group.
You just need to make sure that you are not part of any groups that have the complete privilege Denied.
In Azure DevOps, Deny trumps Allow.
Unless you're a member of the Project Collection Administrators group on your organization, membership in a group that explicitly Denies any permission will deny your permission, even if you are in another group that explicitly Allows you the permission and even if you as an individual user are granted Allow on that permission.
We usually add developer to Contributors.
For the Inheritance part, you could turn on your inheritance and clear explicit with single click for each branch which have explicit permissions.
After this, Contributors Group in other branches will totally inherit the permissions set by root path of your repo/workspace. For example, if root path are Allow, your branches should be Allow(inherited), if it's Deny, your branches should be Deny(inherited).
If a permission isn't directly allowed or denied for a user, then it may be inherited in two ways.
Users inherit permissions from the groups to which they belong. When
a permission is allowed for a user directly or through membership in
a group that has that permission, and it is denied, either directly
or through group membership, the permission is denied.
Members of Project Collection Administrators or **Team Foundation
Administrators** retain any allowed permissions, even if they belong to
other groups that deny those permissions.
Object-level permissions that are assigned for nodes of a hierarchy -
areas, iterations, version control folders, work item query folders -
are inherited down the hierarchy. That is, a user's permissions that
are set at area-1 are inherited by area-1/sub-area-1, if the same
permission is not explicitly allowed or denied for area-1/sub-area-1.
If a permission is set explicitly for an object, like
area-1/sub-area-1, then the parent node is not inherited, regardless
of whether it is denied or allowed. If it's not set, then the
permissions for that node are inherited from the closest ancestor
that has the permission explicitly set.
More details please take a look at our official tutorial here: Inheritance and security groups
After the latest update including the cross-repo policies in the Azure DevOps portal, I can't add project-wide branch protections even though I am the Organization and Project owner.
Is there any special permissions that is required to be assigned to my user?
Thanks,
Ví
Solution:
Leave all security groups except "Project Administrators"
Is there any special permissions that is required to be assigned to my user?
You should check your user's access level, if they are Stakeholder levels, then they will not have the permissions to add project-wide branch protections.
If set my user as Stakeholder levels on the Organization Settings->Users:
Then, my user will get the states: Yo do not have permission to edict project-wide branch policies:
So, to resolve this issue, you should to assign a higher access level to your users, like Basic.
Hope this helps.
I solved the Problem by leaving all groups, except the "Project Administrators" group.
This was based on #ViMans comment.
Quote:
I have realized the problem was related with a user belonging to
different groups with different access level. E.g: An organization
administrator belonging to the contributor group it will keep the most
restrictive access level based in a least privilege philosophy