In our Azure Active Directory we have set up an App Registration for our service connection. The App Registration has Role Contributor for two different Resource Groups that in turn exists in two different subscriptions.
When the service connection is used it is automatically scoped to one resource group in one subscription anyway and this can't be changed.
Looking at Azure DevOps - Service connections we can see that even though the app has access to both subscriptions and resource groups it is in our case already mapped to a specific subscription and resource group.
Add a new service connection, choose Azure Resource Manager, Service Principal (automatic) and set it up against the other subscription or set up a new Management Group.
Related
I am using the Azure Resource Mover under preview.azure.portal to move an app service and its dependencies between subscriptions but keep encountering the following error:
{"code":"ResourceMoveProviderValidationFailed","target":"Microsoft.Web/sites","message":"{"Code":"BadRequest","Message":"Please select all the Microsoft.Web resources from 'SourceTestRG
resource group for cross-subscription migration.
Also, please ensure destination resource group 'DestTestRG'
doesn't have any Microsoft.Web resources before move operation.
Here is the list of resources you have to move together: AzureTestAppTest (Microsoft.Web/sites).
This resource is located in resource group 'SourceTestRG',
but hosted in the resource group 'AppsRG'. This may be a result of prior move operations.
The destination RG 'DestTestRG' does not have any resources.
Any ideas on what may be the issue ?
UPDATE:
So basically the process is as follows ?
Create an App service plan lets say MainAppServicePlan in a ResourceGroup lets say ASPRG1 under subscription MainSub1
You can create resources in different resource groups for example:
App Service: AppService1 in ResourceGroup RGApp1
App Service: AppService2 in ResourceGroup RGApp2
App Service: AppService3 in ResourceGroup RGApp3
But thay all are under the App Service Plan ASPRG1.
That means if i try to move from AppService1 from MainSub1 to MainSub2 it will give an error
because i am required to move AppService2 and AppService3, is that correct ?
If that is the case , wouldn't it be feasible to create a brand new App Service Plan and move AppService1 to that new
AppService Plan and then since no other resource resides in that App Servie Plan then the cross subscription migration should be ok ?
Can the app service plan be changed once it is already set on an app service ?
App Service resources and Resource Groups are tied together internally, and it's not always transparent. See the Move guidance for all considerations.
Specifically:
All App Service resources in the resource group must be moved together.
App Service resources can only be moved from the resource group in which they were originally created. If an App Service resource is no
longer in its original resource group, move it back to its original
resource group. Then, move the resource across subscriptions.
If a blank Azure Subscription is provided, how do you deploy a new Resource Group, and is it free?
And following deployment of a new Resource Group, are there any steps that need to be undertaken before deploying resources to the newly created resource group?
how do you deploy a new Resource Group, and is it free?
There are various API's (REST API, Powershell, Azure CLI) to do this. The easiest is doing it interactively from the Azure portal. A resource group is free
And following deployment of a new Resource Group, are there any steps that need to be undertaken before deploying resources to the newly created resource group?
Generally No. Unless it is locked (by default it isn't) or has specific security stopping you (which won't be an isse if you are the same user)
I'm an owner of an Azure resource group but not have permissions on the subscription or on the management group.
When configuring the "azurerm" provider inside my .tf file, I've added subscription id and tenant id (I'm not the owner of that subscription).
--------------------- UPDATE ---------------------
I'm trying to apply Linux virtual machine using Terraform but having authorization issues while planning the .tf file.
I've listed all my accounts using Azure CLI (want to connect the second subscription in the output below):
I've succeeded authenticating to the subscription using Azure CLI with the command (it worked):
az account set --subscription="SUBSCRIPTION_ID"
It's my default and current subscription:
Also, I was able to create and manage resources inside my resource group in that subscription using Azure CLI.
However, I added the exact tenant ID and the exact subscription ID inside my .tf file and still got the same credentials errors during the "terraform plan".
Using Azure CLI or Azure portal I am able to create and manage resources inside the resource group's scope, although using terraform I'm facing problems.
Thank you :)
According to your story, you just set the tenant id and subscription id in the azure provider, so it seems you authenticate via Azure CLI. No matter you have a user account or a service principal, the owner role of the resource group is enough to create virtual machine in the resource group. In this way, you need to logging into the Azure CLI first. As it shows in the link I have provided.
In my Azure DevOps release pipeline, I would like to start a VM. So I have an "Azure resource group deployment" task with the action "Start virtual machines". However, when I run this task, I get the error:
"Failed to fetch the list of virtual machines from resource group: ...
Error: "Could not fetch access token for Managed Service Principal.
Please configure Managed Service Identity (MSI) for virtual machine
'https://aka.ms/azure-msi-docs'. Status code: 400, status message: Bad
Request"
In my VM I already enabled system-assigned managed identity, so I don't know why this error is appearing. Any thoughts?
You will also need a service connection in Azure DevOps to connect to your Azure subscription using the MSI.
You can configure Azure Virtual Machines (VM)-based agents with an Azure Managed Service Identity in Azure Active Directory (Azure AD). This lets you use the system assigned identity (Service Principal) to grant the Azure VM-based agents access to any Azure resource that supports Azure AD, such as Key Vault, instead of persisting credentials in Azure DevOps for the connection.
In Azure DevOps, open the Service connections page from the project settings page. In TFS, open the Services page from the "settings" icon in the top menu bar.
Choose + New service connection and select Azure Resource Manager.
Choosing a service connection type
Select the Managed Identity Authentication option.
Opening the managed service identity settings
Enter a user-friendly Connection name to use when referring to this service connection.
Select the Environment name (such as Azure Cloud, Azure Stack, or an Azure Government Cloud).
Enter the values for your subscription into these fields of the connection dialog:
Subscription ID
Subscription name
Tenant ID
After the new service connection is created:
If you are using it in the UI, select the connection name you assigned in the Azure subscription setting of your pipeline.
If you are using it in YAML, copy the connection name into your code as the azureSubscription value.
Ensure that the VM (agent) has the appropriate permissions. For example, if your code needs to call Azure Resource Manager, assign the VM the appropriate role using Role-Based Access Control (RBAC) in Azure AD. For more details, see How can I use managed identities for Azure resources? and Use Role-Based Access Control to manage access to your Azure subscription resources.
https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops#create-an-azure-resource-manager-service-connection-to-a-vm-with-a-managed-service-identity
We are building a solution in Azure Government and we will be using Terraform to deploy the solution. Seems the preferred method is to create a Service Principal for Terraform with the Service Principal having the Contributor role scoped to the subscription.
The one issue with this we are looking to solve is that this gives the Service Principal management plane access to the Key Vault...since it is in the subscription. With Contributor role, the service principal is not able to create new access policies (assign itself or others permissions to the data plane) but we are looking for a way that can remove the service principal from having any management plane permissions.
We have tried putting a ReadOnly lock on the Key Vault before creating the Service Principal but the lock does not stop the service principal from getting the Contributor permissions on the Key Vault.
Outside of creating a new role that has Contributor for everything EXCEPT for Key Vault, does anyone have any creative ideas that might help achieve this?
Yes, the root cause of all security issues is that the Service Principal's contributor role assignment is at the subscription level/scope, which enables it to do quite damage specially if multiple applications are deployed to the same subscription (e.g. delete any resource group).
One approach would be:
Provision one resource group for the Azure Key Vault specific to the application and region (the latter in case of geo-distributed applications).
Provision the Azure Key Vault on the resource group created on the previous step.
In our case, the Security Office was responsible for the first 2 steps, where they had monitoring (e.g. email, text-messages, etc.) for any change in the Azure Key Vault (e.g. new keys/secrets/certificates added/deleted/changed, permission changes, etc.).
Provision a second resource group, which will serve as a container for the application components (e.g. Azure Function, Azure SQL Server/Database, Azure Service Bus Namespace/Queue, etc.).
Create the Service Principal and assign the Contributor role to the
application resource group only, for example:
scope =
/subscriptions/{Subscription Id}/resourceGroups/{Resource Group
Name}
Find a sample PS script to provision a Service Principal with custom scope at https://github.com/evandropaula/Azure/blob/master/ServicePrincipal/PS/Create-ServicePrincipal.ps1.
Give appropriate permissions for the Service Principal in the Azure
Key Vault. In our case, we decided to have separate Service
Principal accounts for deployment (Read-Write permissions on keys/secrets/certificates) and runtime (Read-Only permissions on keys/secrets/certificates);
Find a sample PS script to set Service Principal permission on an Azure Key Vault at https://github.com/evandropaula/Azure/blob/master/KeyVault/PS/Set-ServicePrincipalPermissions.ps1.
Having that said, there are lots of inconveniences with this approach, such as:
The process (e.g. via runbook) to provision the Azure Key Vault (including its resource group) and the application resource group will be outside of the main Terraform template responsible for the application components, which requires coordination with different teams/processes/tools/etc.
Live site involving connectivity often involves coordination among multiple teams to ensure RTO and MTTM (Mean Time To Mitigate) goals are achieved.
The Service Principal will be able to delete the application specific resource group when terraform destroy is executed, but it will fail to recreate it when running terraform apply after that due to lack of permission at the subscription level/scope. Here is the error:
provider.azurerm: Unable to list provider registration status, it is possible that this is due to invalid credentials or the service principal does not have permission to use the Resource Manager API, Azure error: resources.ProvidersClient#List: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '' with object id '' does not have authorization to perform action 'Microsoft.Resources/subscriptions/providers/read' over scope '/subscriptions/{Subscription Id}'.".
Yeah, I know, this is a long answer, but the topic usually requires lots of cross-team discussions/brainstorming to make sure the security controls established by the Security Office are met, Developer productivity is not affected to the point that it will impact release schedules and RTO/MTTM goals are met. I hope this helps a bit!