I have an app with 2 slots. I have stored connection strings in the key vault. I have enabled MSI on the app and 2 slots. Also, within the vault's access policy, I have added the app (production slot). However I am not able to add the slots to the access policy. E.g. My app's name is XYZ20180706 and the slots are XYZ20180706/dev and XYZ20180706/test. But when I type in XYZ20180706/dev or XYZ20180706-dev in the service principal, it is not found.
How do I create an access policy for a deployment slot?
Just having it enabled on the main slot is not enough. I currently get access denied (to vault) if I deploy the app to the dev slot and run it.
Thanks.
AFAIK, we could access it after enabling MSI for deployment slot, you could check my test steps.
1.I have two slots, then I enable MSI of both of them in the portal.
You could check them in the Azure Active Directory -> Enterprise applications in the portal, refer to the screenshot.
Note: You should specify the Application Type option with All Applications when you are searching.
3.Add Add access policy in the azure keyvault, you could find the slots in the principle (hover your cursor over it).
On the key vault "Add access policy" section (printsceen 3 from Joy Wang), when you selecting the principal type this: YourWebAppName/slots/YourDeploymentSlotName
After you type the entire string the autocomplete check will be green and you can select the principal from the list.
Related
I have a DevOps release pipeline pushing out (via CLI on a VM) to a dev resource group happily. When I add a stage pushing to an identical QA resource group I get the below.
ERROR: (AuthorizationFailed) The client '' with object id '' does not have authorization to perform action 'Microsoft.Web/sites/config/list/action' over scope '/subscriptions//resourceGroups//providers/Microsoft.Web/sites//config/publishingcredentials' or the scope is invalid. If access was recently granted, please refresh your credentials.
Is there a place I should be looking at first?
The error is due to the service principa(in azure devops, typically is 'service connection') doesn't have correct role/permission on the target resource.
Please find your service connection in Project settings.
Click Manage Service Principal which will redirect you to the Application Registration of the Service Principal. All you need to do here is copy the name (the default format is <account>-<prject>-<GUID>).
Go back and click Manage service connection roles which will redirect you to the IAM blade of the Azure Subscription. Here you need to assign a role to the service principal of which you copied the name of in the previous step. you can add it as subscription owner/contributor role on the target subscription simply.
You can check similar answer here.
I have an Azure App Service Web App using Key Vault References for several application settings. All resources are deployed and configured through an Bicep/ARM template. The secrets in Key Vault and Access Policies are set through the Bicep/ARM template as well. The Web App works great and has access to Key Vault through those references until I re-deploy the Bicep / ARM template to modify some unrelated values. After running "az deployment group create" the references break (showing red cross in application settings). I found two workarounds to make them connect again:
Restart Web App
Create another app setting / modify a setting in the portal and save
I would like to understand the root cause / possible mistake and why the work-arrounds help. I checked, and the Secrets in Key Vault are not changed / updated when re-deploying the template. My assumption is that this is caused by the Key Vault API removing and re-creating the Access Policies each time the template gets deployed. A what-if deployment of the template tells me that the removal and re-creation of the Access Policies is happening.
As mentioned by #Deepdave in the comment section. ARM does not allow a key vault to be redeployed with out clearing existing access polices.
Please submit your feedback here https://feedback.azure.com/forums/34192--general-feedback
I have an Azure Application Gateway in subscription A and a wildcard ssl cert in a Keyvault in subscription B, both under the same tenant. Is it possible to link this certificate to this application gateway?
Continuing on from #andriy-bilous, creating a Managed Identity for an Azure Application Gateway so you can draw down certificates from your Azure Key Vault is pretty simple.
Create the Managed Identity:
Go to Azure Portal.
Select the search bar at the top, then search for and select "Managed Identities".
Select Create.
Enter your new managed identity the relivant Resource Group and Region, and a unique Name.
Now, Review + create, then Create.
Assign the rights to the Managed Identity in your Key Vault:
Go to your Key Vault.
Under Settings, select Access policies.
Select + Add Access Policy.
Under the Secret permissions dropdown, select Get.
Next to Select principal, select None selected.
Search for the Managed Indentity you just created, and Select.
Finally, click Add and you're done.
Head on over to your Application Gateway, and there will be a Managed Idenity for the Key Vault and setup your HTTPS certificates.
Also, as you've aleady got a VNET setup, adding your Key Vault to the VNET via a Private Endpoint is a great idea.
Yes it is possible.
Application Gateway integration with Key Vault requires a three-step configuration process:
Create a user-assigned managed identity
Configure your key vault
Configure the application gateway
https://learn.microsoft.com/en-us/azure/application-gateway/key-vault-certs#how-integration-works
We ran into the same issue. As of Nov 2021, based on the documentation, the Key Vault instance must be in the same subscription as Application Gateway.
Azure Application Gateway currently supports only Key Vault accounts in the same subscription as the Application Gateway resource. Choosing a key vault under a different subscription than your Application Gateway will result in a failure.
I am trying to link Azure Key Vault secrets to a variable group in Azure Pipelines (part in Azure DevOps). Microsoft documentation here.
However, the "Authorize" button does not seem to work. It spins endlessly. Screenshot.
My target Azure Key Vault already has the service principal included in its access policy with Get and List permissions. Screenshot.
Anyone seen this issue before?
This workaround also seems like a bug for Azure Key Vault deployments using ARM templates.
If the service principal in question is added to the Azure Key Vault (AKV) access policies through an ARM template by referencing the service principal's Object ID (as Microsoft documentation calls for), permission errors with Azure Pipelines follow.
However, if I manually add the service principal to the AKV's access policies by referencing the service principal's application (client) ID, the permissions errors go away entirely.
Again, feels like a bug. And now my automated deployment pipeline doesn't quite work because of this manual step.
Also, in the AKV ARM template, if I were to combine the mandatory field objectId with the optional field applicationId, the service principal shows up as a "compound identity". That does not fix the permissions issues in Azure Pipelines. I do not see a way of adding a service principal properly without doing it manually.
Firstly, please make sure the service connection is working correctly. Then refresh the page and try it again. Alternately you can also try in browser inprivate session.
Just as the message said "The specified Azure service connection needs to have "Get, List" secret management permissions on the selected key vault."
Basically, we need to click the "Authorize" button to enable Azure Pipelines to set these permissions for the specific service connection.
If that doesn't work, we can also manually set the permissions for the specific service connection.
Go to Project settings - > Service connections -> Select the
specific ARM service connection
Click Edit to popup the Update Authentication for xxx dialog
Click the "use the full version of the service connection dialog."
link, to get the Service principal client ID
Go to your key vault in Azure portal -> Access Policies -> Add a new
Access Policy -> Select a template (e.g Key&Secret Management) - >
Select Get, List for Secret permissions.
Click Select Principal -> Copy and paste the Service principal client ID
to search the user/application -> Select the searched
user/application
After that you can see the new APPLICATION access policy.
Try it again after successfully adding the application access policy.
UPDATE:
Generally in Azure DevOps we need to create a ARM service connection (the client which can access the azure sources) first before deploying an Azure Key Vault through an ARM template.
Actually when you select the Azure subscription then click Authorize in Azure resource group deployment task
, the ARM service connection is created automatically. You just need to check the AppID and get the ObjectID to use in the ARM template.
We can get the Service principal client ID (AppID) by following above steps. After that we can get ObjectId by the AppID with running the following command: (See Find service principal object ID using PowerShell for details.)
$(Get-AzureADServicePrincipal -Filter "AppId eq 'a89c3dee-f5bf-4ea1-a805-d4c729a4add3'").ObjectId
Then you can specific the ObjectId when deploying the Azure Key Vault through an ARM template.
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!