Azure Devops: securing deployments to on-premise servers at webapp level - iis

It's clear that you can set which roles can deploy to a certain on-premise server thanks to the security settings in Deployment Groups and Agent pools. But, any way of restrict access at webapp level?
The only ways I found are:
Creating a specific account, giving it deploying permissions in target server's IIS in required webapps only and provide this credentials to developers on charge of creating the pipelines for deploying those webapps (they will put them as custom environment vars or similar in pipelines)
Same than 1 but using the created account as a service account for an agent. Access to this agent will be restricted to developers on charge of creating the pipelines for deploying those webapps.
Both cases require to create new accounts and to give permissions on server's IIS. No way of doing this from Azure DevOps on the same way that access to whole servers can be restricted?
Regards.

It's clear that you can set which roles can deploy to a certain
on-premise server thanks to the security settings in Deployment Groups
and Agent pools. But, any way of restrict access at webapp level?
Sorry but as I know Azure Devops Service doesn't support such out-of-box feature.
We can manage the access in Organization level(Organization settings), Project Level(Project settings), Feature Level(Security of Pipelines/Deployment Groups feature...) and even the 'instance Level' (Set security for one specific pipeline/deployment group/one specific git repo).
But the 'instance level' is the lowest level, we can only manage the access in specific pipeline or specific deployment group but not one webapp which will be deployed by pipeline/deploymentGroup.
The webapp is not an option hosted by Azure Devops Service, it's just something to be deployed by pipelines(hosted by Azure Devops Service). So Azure Devops Service avtually have no knowledge about the webapp(it also won't have UI that represents one webapp), that's why we can manage the access in pipeline but not webapp in that pipeline...
Update 1
Once you have only one deployment group for the specific target server, you can determine who can access the deployment group here:
The person who is assigned with reader permission can't use the deployment group to do the deploy.

Ok, following the suggestion from #Lance and after some research, this is what I´m planning to do:
Creating a custom service connection where following fields can be set: IIS Server where the WebApp is, Webapp name, User (with permissions to deployment) and Password.
Together with the Custom Service connection I will provide a custom task where developer team can select the service connection against they want to do the deployment (obviously, server admins will only configure service connections to webapps which this team is allowed to deploy).
Agent will run with a low-privileged account (no way of affecting any app) and the custom task will use internally the creds provided on service connection to perform the deploying.
I think that approach is the best workaround to the initial problem and can be extensible to fix the granularity problem in other kinds of resources (like DB´s, Shared Folders, ...) just simply adding another specific custom service connection (to specify the resource and the deployment credentials) and a linked Custom task which allows deployments only against that resource.
The only drawback is the fact that, if you want to set a deployment approval, you have to do it at resource level (for every webapp, for every DB, ...) and that means that approvers will have to approve resource by resource when deploying also (instead of a single approval for the whole application deployment as, in my understanding, should be)
What do you think guys? Any remark before start coding this?
Regards.

Related

Azure DevOps agent pool creating using Terraform

I need to create Azure DevOps agent pool using Terraform.
In Terraform I'm using microsoft/azuredevops provider. And resource azuredevops_agent_pool
In conclusion, I have an error Error creating agent pool in Azure DevOps: Access denied. user needs Manage permissions to perform the action. For more information, contact the Azure DevOps Server administrator.
I have Administrator permissions in Azure Devops.
What can I try with this error?
UPD. I can create agent pool from Web UI azuredevops.
I am using authentication with PAT. PAT configured for FULL access.
UPD2. I understood that access on Project Level is other than access on Organization Level. So I have full access on Project Level but terraform is trying to create agent pull on Organization Level.
It's not possible at the moment. I face the same issue.
The issue is still opened since 2020.
https://github.com/Azure/terraform-azurerm-aci-devops-agent/issues/4
As mentioned on the README.md
Before running this module, you need to create an agent pool in your
Azure DevOps organization and a personal access token that it
authorized to manage this agent pool.
So it's not possible to automatically create an agent pool from the official Terraform azure DevOps provider
You might try to find a way through Azure DevOPS REST API:
https://learn.microsoft.com/en-us/rest/api/azure/devops/distributedtask/elasticpools/create?view=azure-devops-rest-7.1
You might also find this GitHub issue comment useful:
https://github.com/microsoft/terraform-provider-azuredevops/issues/204#issuecomment-962504540
Someone has already developed a way to do with Terraform using local-exec combined with azure cli/PowerShell/rest api

Assign the Service Connection User a role through ARM template

We just started recently using App Configuration Service in Azure for some of our applications.
As part of the setup, we removed Access Keys as a possible authentication method. This works pretty well, we have assigned dataowner rights to our team so that they can manage the service and everyone is happy.
We came up with the brilliant idea of using the app config service in our build and release yaml pipelines. We found a suitable task, but the user that is attached to the service connection that we use in Azure Devops to deploy to Azure does not have the rights to access the configuration store.
We want to be able to assign this right in the arm template we created for the app config service. The issue though is that we cannot find the principle id assigned to that user.
Honestly, I am not that experienced with AAD, so I am probably missing something here. The ServicePrincipleId does not work, whenever I try to use it, azure tells me that that user does not exist. I get redirected to an app-registration page whenever I try to manage the service connection, which I don't understand either.
Next steps for me will be to get our admin to manually assign this right to the Service Connection User and see if I can extract the principle Id from that role assignment.
My question(s) would be, why doesn't the service principle work? How do I extract the principle id from the service connection?
Could you please try below steps?
In Azure DevOps, go to the project that contains your target pipeline. In the lower-left corner, select Project settings.
Select Service connections.
Select Manage Service Principal.
From there, you should be able to find the objectId of your Service Principal, which uniquely identifies your SP.
Also these posts are great resources to learn about AAD Apps and Service Principals:
https://learn.microsoft.com/en-us/azure/active-directory/develop/app-objects-and-service-principals
https://stackoverflow.com/questions/54066287/azure-service-principal-id-vs-application-id#:~:text=objectId%20will%20be%20a%20unique,will%20be%20same%20as%20appId%20.

Architecture Resources in Azure Resource Manager

We are developing applications in .Net and deploying them to Azure app services. We currently have a multi-tier environment (QA/STG/PROD). In order to replicate the same environments we are using slots. However, the issue with slots is all developers who has access to QA slot are able to view/modify STG / PROD slot settings. We want to segregate this with authorization where-in users should only be able to publish apps on QA. Should we still use slots or we go with separate web apps?
As suggested in one of the comments you can use RBAC (Role Based Access Control) to control the user permissions on the web app/slots.
Azure RBAC has three basic roles that apply to all resource types:
Owner has full access to all resources including the right to delegate access to others.
Contributor can create and manage all types of Azure resources but can’t grant access to others.
Reader can view existing Azure resources.
So, you could add the developers as a READER to the webapp and as a CONTRIBUTOR to one of the slots. This will prevent the web app changes
Further, you can customize the RBAC to suit your requirements.
You can create a role with custom
Refer this article:
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-custom-roles/
You can go with slots. Each slot creates a separate URL and you could control access to the slots by Authenticating using AD.
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-active-directory-authentication/

Does Azure Cloud Service Publishing Profile Exists?

I need to assign publish permission to one of my developers so that he should be able to publish to only one cloud service & do not affect others.
Azure websites have these concepts called download publishing profile.
I could not find anything similar for cloud service. Can it be
achieved?
As you know Azure Management Portal does not have any role defined where we could map a user account login to manage a set of resources (say cloud service 1 & 2)
It is not possible as of today. It seems that it should be possible with Resource Groups and Role Based Access Control (RBAC) however currently cloud services can't be added in resource groups and assigned RBAC.
One way you could achieve this is have a custom application consuming Service Management API and implement your own RBAC in that application. However it is still a "hack" and not proper solution.
Why don't you try using "publish from source control"? When the developer checks in it will auto publish the code.
I believe the new portal will allow the creation of roles for publishing profiles; it already allows adding additional users to your organization; but to get what you want for now; publishing from source code should do the trick.

Deploying WebRoles to pre-existing VMs

We have developed and tested our webroles in our Free trial Azure cloud.
We now have to deploy the webroles to Company A Azure cloud. Company A is open to creating IIS VMs for our deployment but will not share username/pwds with us to publish our Webroles to their cloud.
This should be a pretty common scenario, would like to hear from folks who have solved it in their deployments.
How do we publish web roles to a pre-existing VM?
This isn't how Web Roles work. A Web Role (along with any other defined roles) is essentially a bundle of code, startup scripts, binaries, etc. that are needed on the VM. The VM itself is stateless: It's started up as a fresh (up to date) copy of Windows Server, and your code is executed. Anything needing install is done via your startup scripts.
You cannot push a Web Role independently to an existing Virtual Machine. You'd need to take your actual code project (e.g. asp.net) and publish that to a pre-existing VM, without any of the Web Role scaffolding. How you do that would be up to you (and the folks who are managing these VMs).
I guess there is a confusion with different concepts.
From what I understand you have already deployed your cloud service and associated web roles to a trial azure subscription. You were able to do that because you are the admin of the subscription. If you need to deploy the same set of roles and the cloud service to one of your customers azure subscription they will need to setup your account as a co-admin so you can follow the same deployment procedure you did with your trial subscription. They don't need to give you a user/pass pair. They just need to give your LiveID or appropriate credentials a temporary co-admin permission to do the deployment on their behalf. They can do this in the azure management portal.

Resources