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.
Related
I am writing a Github App that is able to create repositories in an installation.
When the App acts on behalf of an authenticated user, I would like to check that the user can (by themselves) create a repository in the org.
I have spent a lot of time on GitHub's API docs, but I cannot find the answer.
My first thought was that this info should be available in the endpoint /user/installations. The endpoint lists the installations that the user can access (either as a member of an organization or as an external collaborator). However, the permissions returned with each entry are actually the permissions for the App, not for the user. So, this is a dead end.
Another direction was looking at the (public+private) organizations of the user using /user/orgs.
(This does not seem the right direction because as an App I would expect to operate only on installations...)
With this endpoint, I can get all the organizations of the user. However, I don't get whether they can create repos and/or what the role of the user is in the organization.
Should I use the teams/roles part of the API?
My App doesn't ask for the members suite of permissions so I would like to avoid this road.
At this point, the only workarounds are:
Try to create the repo as the user, take note if it fails. Bad solution because I don't want to tell the user that they can create a repo if they can't.
In the background, try to create a repo as the user to check if it possible. If it is, delete the repo. This works but it seems an ugly workaround.
Any suggestion?
When I create a service principal it also creates an App in Active Directory.
az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/123456a1-a1b2-1234-12ab-12a3b4cdef67"
If I go to the Azure Portal - Active Directory - App registrations it shows all the applications registered.
I have managed to find the service principal I use for terraform by matching the terraform client_id with the Azure "Application (client) ID". It also had a human readable display name (although not the best since I still had to look via client id!)
However, there are several others where the display name is just "project_subscription".
They look like they must have been generated automatically when setting up a pipeline registering a web app in the portal or something.
I can't tell if they are actually used or if they were just created for experimenting and are then left over.
How do I know what they are for and if they are still used or not?
Is it possible to search Azure for the id or anything?
Is it possible to add a description to these to identify what they are used for beyond just the display name?
e.g. I only identified the terraform one by matching up the id with my code
App registration can be used for many scenarios, the app registrations in your AAD tenant should be created by different users. There is no such thing as a description of them.
To see if they are used, it needs to combine the context, as in AAD, there are different usages for them. For example, there are no sign-in logs of the AD App's corresponding service principal, but you cannot make sure if it was used as a client app. For the details, you may need to check the Audit logs.
For more details about AD App(App Registration) and service principal, you could check this doc - https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
Objective: Allow different clients access to only read/pull from my private repo.
Overview:
Listed are the different options that I am aware of:
I could invite the clients and give them access to the Basic access level but do know what to have to pay for different users just to read/clone from the repo.
I could create a single user with Basic access level and then create git access tokens for them individually. However, I did not see a way to restrict the access tokens to be project/repo specific. Instead, the access tokens create had the same privileges as the created user.
Question: What is the best practice to provide access to an external user to only access the private Azure DevOps repo?
Note: I have seen this link and did not know if there were other options.
To make the user only have read access to all repos in one project:
You may consider making the user a reader instead of contributor or Project Administrators, so the user can have only read access to the repos in one project.
Organization Settings=>Users(General)=>Manage user=> select Project reader.
More details about project readers you can check this document.
To make the user only have read access to one special repos in one project:
We can control related permissions from Project Settings=>Repositories(Repos)=>Version Control Administrators:
Hope all above helps :)
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.
If I create an Azure Artifact feed and reference it form a build, will the build continue to function if I am, as feed owner, removed from the organisation?
Yes, the feed will continue to exist, and assuming you gave the appropriate build identity access to the feed, your builds will continue to have access to the feed.
Members of the Project Collection Administrators group (effectively, your organization administrators) will remain owners of the feed and can give permissions to other users.