We're using yaml pipelines with environment agents installed on local infrastructure. Each Environment is backed by a Deployment Pool which is implicitly created by AzDO. The pools reside at the org level.
Every time someone adds an environment to a pipeline it requires the project collection admin to authorize the pipeline. The devs cannot authorize the pipeline because they don't have permission at the org level. Image below shows prompt received.
Is there anyway to simplify this so the PCA is not required to authorize every on-prem pipeline?
No, we do not have any methods to skip the permit from PCA, when a pipeline is trying to target to an environment at the first time.
On the Organization Settings and Project Settings, we also do not have any built-in options to defaultly permit all new environments on all pipelines.
This is aiming to prevent the environments from being abused.
Related
Let's say I have a YAML pipeline, releasing to dev and prod, and I want to set an approval before releasing to production.
Currently, this can be done via Environments approvals (MS Docs - Define approvals and checks).
However, this seems to work only for virtual machines.
How can I set an approval when releasing to Azure PaaS components, e.g. Azure function or Azure App Service?
To achieve this, go to service connection that is used to connect to cloud env, and set the approval there.
Project settings -> service connections -> select your connection (prod) -> click the three dots -> approvals and checks.
In your pipeline you need to define a deployment job, specifying an Environment which is configured to require an Approval.
We have a set of privileged operations which we would like to secure. We are considered pulling up a custom build agent and deploy the privileged operations to this agent. Which custom tasks a Azure Pipelines user would be able to execute these operations. It should not be allowed to run arbitrary custom scripts through pipeline tasks such as the Az Cli task, or PowerShell task.
Microsoft is stating in the documentation that it is possible to control the available tasks for a custom build agent. Refer to https://learn.microsoft.com/en-us/azure/devops/pipelines/security/misc?view=azure-devops#control-available-tasks
Unfortunately the documentation is not clear on how this can be configured.
How can I configure this?
You can set it on organization level in the Settings tab
Let say I have 2 Deployment Groups Named QC and Production, each one contains X number of servers.
I also have a Release Pipeline with 2 stages QCStage,ProductionStage.
How can I set my permissions,on Deployment Group Level, so that users can't deploy to Production?
I can achieve this using "Pre-deployment approvals" on each stage but I have hundreds of Pipelines,
we can't be setting permissions for every stage for every pipeline
Update:
This doesn't see to be supported on Azure DevOps,a new Feature Suggestion has been created:
Prevent users from deploying to a Deployment group using Deployment Group Permissions (not on each Stage)
How prevent users from deploying to a Deployment group
Answering this question at two different scope levels.
Scope 1:
Take a simple sample, there has 2 deployment groups in your project: QA and Product.
If what you want is some of users can deploy to QA but not Product, I'm afraid this hasn't been expanded into azure devops until now.
Now for azure devops service, we provide 3 permission level controlled: collection, project and object. Deployment group is the one which belong to object level permission. We haven't provided more granular permissions control, like setting permission on one specific deployment group at this scenario.
Scope 2:
Just restrict someone to deploy a release.
As you know, Deployment group are used for a release stage. In this scenario, in order to control who can/can't deploy a release, please use the release permissions. BUT, there has one disadvantage that it work only for manually initiated releases.
So, I'm afraid Approvals on release stage is another and better option for you to make use until now.
I currently have a release pipeline with a number of stages. In the Deployment group job I have to specify Deployment group (which is fine), but in order to run my pipeline on a specific VM(agent) in that group I also have to specify some tags to limit the number of matching targets.
Instead of using tags in the Deployment group job I would like to use a variable to specify which VM(agent) to use. This variable can then be set when the release is created. Is this something that can be achieved in some way?
I think that the only way to do this would be through Agent capabilities.
In self-hosted agents a capability is:
Capabilities are name-value pairs that are either automatically
discovered by the agent software, in which case they are called system
capabilities, or those that you define, in which case they are called
user capabilities.
Under your Agent pools if you select your agent you will discover a tab Capabilities.
For self-hosted, you could determine a user-defined capability. These means to have a capability you will later check during release time.
How could you provide that info? In your YAML you will specify:
pool:
name: Default
demands: SpecialSoftware # Check if SpecialSoftware capability exists
What this will do is only agents that meet those capabilities will be suitable to perform the deploy
And remember this if anyone finds this answer, for Microsoft hosted agents:
Demands and capabilities apply only to self-hosted agents. When using
Microsoft-hosted agents, you select an image for the hosted agent. You
cannot use capabilities with hosted agents.
I have several self-hosted Azure DevOps agents (each installed on a dedicated on-prem server) and I need to perform reoccurring maintenance on them (i.e. patching, etc.). Is there's a good way to define those maintenance windows within Azure DevOps so that server admins could do their job without worrying to interrupt any ongoing build/release task?
There seem to be a setting related to configuring reoccurring maintenance (Organization Settings -> Agent Pools -> <Pool Name>-> Settings [tab]) but it seems as if it would apply to the whole pool and it's hard to tell which of the agents will be considered offline at which time slot.
Unfortunately I couldn't find any documentation about it and not sure if there's something that Azure DevOps would also be doing on the agent machines (i.e. running cleanup, updating agents and so on)
Currently, the process involves a person with admin permissions in Azure DevOps to disable an agent allowing a server admin to perform regular maintenance and to re-enable it back when server admin is done. It would be great if a server admin could not involve an Azure DevOps Admin every time for such routines.
Due to the fact that you have your own Azure Pipelines agents, then the maintenance should be easier and you will have total control of either having automatic maintenance or not. If you use Microsoft's hosted agents, you could not update the hosted agents from Microsoft because these agents are maintained by Microsoft exclusively.
The best way to do this is by having more than one agent on one machine instance then organize the agents on one pool. If you have multiple pools, then you can configure Azure DevOps to have different maintenance window schedule on each pool to have different time, and give some time to download and configure itself.
For example, I usually configure the maintenance window on weekend days such as Sunday early morning once a month on certain date. And for any pools I have I gave them intervals of 40 minutes on each pool to have maintenance to give enough time for the agent to download, update and restart itself.
Please consult these documentation further for detailed explanation and use cases:
For Azure DevOps Server:
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops-2019
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=azure-devops-2019
For Azure DevOps Service (on cloud TFS, formerly Visual Studio Team Services):
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/agents?view=azure-devops
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/pools-queues?view=azure-devops