Any way to limit which pools can contribute to an Artifact feed? - azure-devops

Given an Azure Artifacts Feed named 'deployables' (available to the Organization as a whole) and two Azure Pipelines agent pools (named 'Corporate' and 'Testing').
Is there a way to give the Corporate agent pool contributor access to the 'deployables' Artifacts feed but not to the 'Testing' pool?

Is there a way to give the Corporate agent pool contributor access to
the 'deployables' Artifacts feed but not to the 'Testing' pool?
I'm afraid Azure Devops does not provide the direct feature that agent pool can be limited to access Artifacts.
But as workaround, you can through specify the permission of user/group to achieve this indirectly. For instance, there is a group A which have access permission of Artifacts Feed 'deployables'. Give this group the access permission of 'Corporate' pool, BUT denyied in 'Testing' pool.

Related

How can we limit a user to see and run only specific JFrog Pipelines?

Can we assign role based access control (RBAC) rules to control which users can access and run which pipelines?
RBAC for JFrog Pipelines is integrated with JFrog Access. Pipelines sources can be attached with various permissions to allow admins to control access.
Refer documentation here

Service Principal for Devops Artifact Feeds

we use a devops artifact feed to store our packed/shaded java binaries inside a private project. Now we would like to allow access to certain artifacts for externals.
We will promote these artifacts to a custom view (#public-releases) and want to allow access to this view for certain customers only (s.t. they can use it in their automation).
Is it possible to have some kind of service-account/service-principal to assign read-permissions in devops?
I know it the other way round (give devops access to azure ressources via service connections), but now I want to permit access to Devops Feeds.
How would I create such a User? We have azure AD connected, so maybe that is an option?
Is it possible to have some kind of service-account/service-principal
to assign read-permissions in devops?
No, no such design.
Service principal of Azure Active Directory concept can not be managed as an account in DevOps side(DevOps doesn't have such account type, only internal service principal, no AAD service principal).
As you know, service principal of AAD can manage access to services in azure portal. This is the usual usage. Another usage is Authenticate with Azure Active Directory (Azure AD) tokens, this approach can be used to manage PAT of DevOps, but anyway you end up needing to access the feed based on a legitimate account under the DevOps concept.

which user do Azure devops pipelines run as?

we have azure devops pipelines to build and deploy various projects.
Rccently, we wanted to use the "azureblog file copy" pipeline to copy some files to a blob storage.
This needs write access to the storage account over in azure.
Our administrator says that the pipeline runs as whoever manually runs the pipeline. If this is true, we would have to give all devs and users read/write access to the blog storage, which would be crazy.
I assume he is wrong, and that pipelines run as a specific designated user no matter how they were kicked off. The question is, how to find out what this user is for a given pipeine?
The "edit pipeline" has a security tab near the top, adn this lists a but of "Azure Devops groups", which are presumably groups who have the ability to run the pipelines.
But where is the pipeline user defined?
which user do Azure devops pipelines run as?
It depends on the context in which you are discussing the question.
If you mean inside a pure DevOps service, then I can tell you that the user that the pipeline runs on is not the one who triggers the pipeline (which is the case with native DevOps services by default, unless you install some weird extension or have a problem with the pipeline special design), but this identity:
<Project Name> Build Service Account
'run as someone' is just a property of pipeline run. Pipeline run as 'Build Service Account'(On the DevOps side), If you need a pipeline to download or upload an artifact, you can clearly feel this. If the account mentioned above has no permission, you can't do anything.
If you mean the user's operations based on the Azure side, then I can tell you that for native DevOps service, the 'user' that the pipeline performs operations on the Azure side is not the person who triggers the pipeline. The pipeline of DevOps service consists of multiple tasks, and tasks generally interact with other services through service connection (you can find this in Project settings).
There are many types of service connections. When interacting with services in Azure, this type is generally used:
Azure Resource Manager -> Service principal
When you create a service connection of this type on the DevOps side, Azure will also create an AAD app related to this service connection, and this ADD app corresponds to a service principal in Azure. In Azure, permissions are assigned based on service principals or users, and your DevOps pipeline's operations to Azure are based on this service principal and have nothing to do with anything else in DevOps. On the Azure side, this service principal can be considered as an Azure-side 'avatar' of the tasks of the DevOps pipeline.
If you are interacting with Azure through pure code/pure script, then please follow the logic of the script/code.
Our administrator says that the pipeline runs as whoever manually runs
the pipeline. If this is true, we would have to give all devs and
users read/write access to the blog storage, which would be crazy.
For native DevOps service, of course not. Unless this pipeline has a special design.
I believe the pipeline runs as the "agent". Who the "agent user" is will depend on, first, whether you've chosen a "Microsoft-hosted" or "self-hosted" agent to run your pipeline.
When running pipelines in Azure DevOps that are directly working with Azure Resources you need an Azure Resource Manager service connection. The credentials used to make the service connection are the credentials the pipeline will use when it runs.
You can have your administrator provide you with an Azure AD account that has the permissions you need and then use that Azure AD account to create the service connection for the pipeline. Once you have created the service connection you can use the ResourceID of that connection in place of you azureSubscription.
Here is the link to the Microsoft documentation on creating a service connection.
Here is the link to the Microsoft documentation on the Azure file copy task. To verify you can use the service connection in place of the azureSubscription.

How can we implement security for agent pools in Azure Devops

How can we restrict access to agent pools for certain groups in azure devops. As of now everyone has the access to agent pool . I need to manage that access. Any one please help
In the Azure DevOps agent pool, We can configure different permissions by updating user roles. Such as configure the agent permissions to restrict user or group access the agent pool.
Steps:
Open org setting-> agent pools->select agent pool->click the tab Security->remove the user or permission group
Result: the user or group member cannot access the agent pool.
Please refer the doc Security of agent pools and About security roles for more details.

Azure DevOps, what are the default role assignments for the Resource Group?

I have an Azure DevOps release pipeline which deploys a resource group. I have switched the service connection that is assigned to the Create Resource Group task to a different service principal, and now deploying the resource group (after deleting it) succeeds, but I can no longer see it in the portal. Previously, the RG made me a Contributor implicitly without me having to do anything. I am the owner of the release pipeline.
Why does changing the service principal that deploys the resource group give the resource group a different set of role assignments and how do I control the set of role assignments applied to the resource group when it is created so that I am made an Owner? I don't inherit any Owner permissions from the susbcription because I'm not an admin user, any permissions I have - which I still have against an identical resource group - were assigned directly to the RG on its creation, but I can't see how that happens.
you dont have enough permissions. it doesnt have to do anything with Azure Devops. Azure Devops doesnt assign any permissions to the created resource group to the pipeline owner (or anybody else).
one reason why that might happen - you filtered out the subscription the resource group is in. (like tom mentioned in the comment)