Validation Error in APIM Policy for Websocket - azure

I am trying to add policy to the websocket endpoint in Azure API Management through ARM template but I am getting error
"error": {
"code": "ValidationError",
"message": "Not allowed at 'Api' scope for 'WEBSOCKET' api type"
}
I am able to add the policy manually, but I am unable to add the policy to web socket through ARM template. I have tried the same policy to web api its successful.
ARM template for just policy I was trying to see if it can be deployed after the websocket is provisioned:
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"ApimServiceName": {
"type": "String"
},
"policypath": {
"type": "String"
},
"Environment": {
"type": "String"
},
},
"variables": {
"env": "[concat('test-', parameters('Environment'))]",
"svc": "[concat('testsvc-', parameters('Environment'))]"
},
"resources": [
{
"type": "Microsoft.ApiManagement/service/apis/policies",
"apiVersion": "2022-04-01-preview",
"name": "[concat(parameters('ApimServiceName'), '/', variables('env'), '/policy')]",
"dependsOn": [],
"properties": {
"value": "[parameters('policypath')]",
"format": "rawxml-link"
}
}
]
}
entire arm template which I used to deploy both websocket and policy is here(I have tried to directly add the policy instead of sas link for policy).

I am able to figure out a workaround, when I directly add the policy to the operation it works. even then, I have to write the policy directly in the same file the arm template way of providing the file with SAS is not working. here is the current version of code.
{
"properties": {
"value": "<!--\r\n IMPORTANT:\r\n - Policy elements can appear only within the <inbound>, <outbound>, <backend> section elements.\r\n - To apply a policy to the incoming request (before it is forwarded to the backend service), place a corresponding policy element within the <inbound> section element.\r\n - To apply a policy to the outgoing response (before it is sent back to the caller), place a corresponding policy element within the <outbound> section element.\r\n - To add a policy, place the cursor at the desired insertion point and select a policy from the sidebar.\r\n - To remove a policy, delete the corresponding policy statement from the policy document.\r\n - Position the <base> element within a section element to inherit all policies from the corresponding section element in the enclosing scope.\r\n - Remove the <base> element to prevent inheriting policies from the corresponding section element in the enclosing scope.\r\n - Policies are applied in the order of their appearance, from the top down.\r\n - Comments within policy elements are not supported and may disappear. Place your comments between policy elements or at a higher level scope.\r\n-->\r\n<policies>\r\n <inbound>\r\n <base />\r\n </inbound>\r\n <backend>\r\n <retry condition=\"#(context.Response.StatusCode >= 400)\" count=\"2\" interval=\"1\" first-fast-retry=\"true\">\r\n <choose>\r\n <when condition=\"#(context.Response != null && context.Response.StatusCode >= 400)\">\r\n <set-backend-service base-url=\"wss://\" />\r\n </when>\r\n <otherwise />\r\n </choose>\r\n <forward-request />\r\n </retry>\r\n </backend>\r\n <outbound>\r\n <base />\r\n </outbound>\r\n <on-error>\r\n <base />\r\n </on-error>\r\n</policies>",
"format": "xml"
},
"type": "Microsoft.ApiManagement/service/apis/operations/policies",
"apiVersion": "2022-04-01-preview",
"name": "[concat(parameters('ApimServiceName'), '/', variables('env'), '/onHandshake/policy')]",
"dependsOn": [
"[resourceId('Microsoft.ApiManagement/service/apis', parameters('ApimServiceName'), variables('env'))]"
]
},

Related

Azure Policy - GitHub Actions - Authoring Custom Policies

I'm working on testing out using GitHub and GitHub Actions to do policy as code for Azure. I have been successful in following the tutorials that Microsoft has where you export the policy you want to manage to GitHub from the Azure portal. This works fine and I'm able to edit and run the workflows to update Azure with changes to policies.
What I'd like to know is, can you create NEW policies in GitHub and push them to Azure? It seems that you need to first export a custom policy from Azure into GitHub, then you can manage that policy. I say this because when I create a new policy and a workflow for that policy I get the following error in GitHub from the workflow:
> Did not find any policies to create/update. No policy files match the
> given patterns or no changes were detected.
The policy I have in the folder is called "policy.json"
I also see:
Error occured while reading policy in path :
policies/global_tagging_policy. Error : Error: Path :
policies/global_tagging_policy. Property id is missing from the policy
definition. Please add id to the definition file.
That leads me to believe I need an ID prior to being able to push a policy, that says to me that Azure must have assigned one... I can't just make one up.
This is the policy I'm trying to push - just a tagging policy for testing, I don't have an ID in there, I read that you don't need to add one... that Azure would do it for you. Am I wrong?:
{
"properties": {
"displayName": "test-policy",
"description": "this is a test policy",
"mode": "indexed",
"parameters": {
"tagName": {
"type": "String",
"metadata": {
"displayName": "Tag Name",
"description": "Name of the tag, such as 'environment'"
}
},
"tagValue": {
"type": "String",
"metadata": {
"displayName": "Tag Value",
"description": "Value of the tag, such as 'production'"
}
}
}
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Resources/subscriptions/resourceGroups"
},
{
"field": "[concat('tags[', parameters('tagName'), ']')]",
"exists": "false"
}
]
},
"then": {
"effect": "modify",
"details": {
"roleDefinitionIds": [
"/providers/microsoft.authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
],
"operations": [
{
"operation": "add",
"field": "[concat('tags[', parameters('tagName'), ']')]",
"value": "[parameters('tagValue')]"
}
]
}
}
}
}
This tripped me up too so I did some exploring of the APIs and files. I've written about this in greater detail here.
To create a custom Policy, Initiative or Assignment file using GitHub Actions you'll need to generate an id, name & type at the root of the JSON.
The name property needs to be unique at the scope you assign it, I use GUIDs for this but you don't have to. Bear in mind if you define/assign at the Management Group scope then the name needs to be 24 characters or less.
The type denotes the type of file, the options are:
Microsoft.Authorization/policyDefinitions --> Policies
Microsoft.Authorization/policySetDefinitions --> Initiatives
Microsoft.Authorization/policyAssignments --> Assignments
The id is a bit more complex, and is a concatenation of the name and type values with other values mixed in.
The prefix depends on the scope which you want to define your Policy/Initiative/Assignment.
For Management Groups it would be:
/providers/Microsoft.Management/managementGroups/00000000-0000-0000-0000-000000000000
Subscriptions would be:
/subscrptions/00000000-0000-0000-0000-000000000000
Resource Groups:
/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup
This is followed by: providers in all cases
Next is the type value, so whatever you've used for that use again here.
Finally the last segment of the id is the same value you've used for the name property.
In one line that is
/{scope}/providers/{type}/{name}
So as an example:
Policy Definition scoped at a Management Group
{
"id": "/providers/Microsoft.Management/managementGroups/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policyDefinitions/5f44e572-5d2d-4edf-9d61",
"name": "5f44e572-5d2d-4edf-9d61",
"type": "Microsoft.Authorization/policyDefinitions",
"properties":{}
}
Policy Definition scoped at a Subscription
{
"id": "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policyDefinitions/8e4a8c58-1938-4467-8698",
"name": "8e4a8c58-1938-4467-8698",
"type": "Microsoft.Authorization/policyDefinitions",
"properties":{}
}
Initiative scoped at a Management Group
{
"id": "/providers/Microsoft.Management/managementGroups/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policySetDefinitions/be09f23f-0252-4d8a-a805",
"name": "5f44e572-5d2d-4edf-9d61",
"type": "Microsoft.Authorization/policySetDefinitions",
"properties":{}
}
Initiative scoped at a Subscription
{
"id": "/subscriptions/00000000-0000-0000-0000-000000000000/providers/Microsoft.Authorization/policySetDefinitions/8e4a8c58-1938-4467-8698",
"name": "8e4a8c58-1938-4467-8698",
"type": "Microsoft.Authorization/policySetDefinitions",
"properties":{}
}

Enable HTTPS on Azure Front Door custom domain with ARM template deployment

I am deploying an Azure Front Door via an ARM template, and attempting to enable HTTPS on a custom domain.
According to the Azure documentation for Front Door, there is a quick start template to "Add a custom domain to your Front Door and enable HTTPS traffic for it with a Front Door managed certificate generated via DigiCert." However, while this adds a custom domain, it does not enable HTTPS.
Looking at the ARM template reference for Front Door, I can't see any obvious way to enable HTTPS, but perhaps I'm missing something?
Notwithstanding the additional information below, I'd like to be able to enable HTTPS on a Front Door custom domain via an ARM template deployment. Is this possible at this time?
Additional information
Note that there is a REST operation to enable HTTPS, but this does not seem to work with a Front Door managed certificate -
POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/frontDoors/{frontDoorName}/frontendEndpoints/{frontendEndpointName}/enableHttps?api-version=2019-05-01
{
"certificateSource": "FrontDoor",
"protocolType": "ServerNameIndication",
"minimumTLSVersion": "1.2"
}
There is also a Az PowerShell cmdlet to enable HTTP, which does work.
Enable-AzFrontDoorCustomDomainHttps -ResourceGroupName "lmk-bvt-accounts-front-door" -FrontDoorName "my-front-door" -FrontendEndpointName "my-front-door-rg"
UPDATE: This implementation currently seems to be unstable and is working only intermittently, which indicates it may not be production ready yet.
This now actually seems to be possible with ARM templates, after tracking down the latest Front Door API (2020-01-01) specs (which don't appear to be fully published in the MS reference websites yet):
https://github.com/Azure/azure-rest-api-specs/tree/master/specification/frontdoor/resource-manager/Microsoft.Network/stable/2020-01-01
There's a new customHttpsConfiguration property in the frontendEndpoint properties object:
"customHttpsConfiguration": {
"certificateSource": "AzureKeyVault" // or "FrontDoor",
"minimumTlsVersion":"1.2",
"protocolType": "ServerNameIndication",
// Depending on "certificateSource" you supply either:
"keyVaultCertificateSourceParameters": {
"secretName": "<secret name>",
"secretVersion": "<secret version>",
"vault": {
"id": "<keyVault ResourceID>"
}
}
// Or:
"frontDoorCertificateSourceParameters": {
"certificateType": "Dedicated"
}
}
KeyVault Managed SSL Certificate Example
Note: I have tested this and appears to work.
{
"type": "Microsoft.Network/frontdoors",
"apiVersion": "2020-01-01",
"properties": {
"frontendEndpoints": [
{
"name": "[variables('frontendEndpointName')]",
"properties": {
"hostName": "[variables('customDomain')]",
"sessionAffinityEnabledState": "Enabled",
"sessionAffinityTtlSeconds": 0,
"webApplicationFirewallPolicyLink": {
"id": "[variables('wafPolicyResourceId')]"
},
"resourceState": "Enabled",
"customHttpsConfiguration": {
"certificateSource": "AzureKeyVault",
"minimumTlsVersion":"1.2",
"protocolType": "ServerNameIndication",
"keyVaultCertificateSourceParameters": {
"secretName": "[parameters('certKeyVaultSecret')]",
"secretVersion": "[parameters('certKeyVaultSecretVersion')]",
"vault": {
"id": "[resourceId(parameters('certKeyVaultResourceGroupName'),'Microsoft.KeyVault/vaults',parameters('certKeyVaultName'))]"
}
}
}
}
}
],
...
}
}
Front Door Managed SSL Certificate Example
Looks like for a FrontDoor managed certificate you would need to set:
Note: I have not tested this
{
"type": "Microsoft.Network/frontdoors",
"apiVersion": "2020-01-01",
"properties": {
"frontendEndpoints": [
{
"name": "[variables('frontendEndpointName')]",
"properties": {
"hostName": "[variables('customDomain')]",
"sessionAffinityEnabledState": "Enabled",
"sessionAffinityTtlSeconds": 0,
"webApplicationFirewallPolicyLink": {
"id": "[variables('wafPolicyResourceId')]"
},
"resourceState": "Enabled",
"customHttpsConfiguration": {
"certificateSource": "FrontDoor",
"minimumTlsVersion":"1.2",
"protocolType": "ServerNameIndication",
"frontDoorCertificateSourceParameters": {
"certificateType": "Dedicated"
}
}
}
}
],
...
}
}
I was able to successfully make an enableHttps REST Call using the Azure Management API.
I got a successful response and can see the resource results in the portal.azure.com and resource.azure.com sites.
However I am pretty sure the Management API, and PowerShell methods are the only ways supported right now. Since there is likely some validation required on the Certificate and Handling, they didn't include that yet in the ARM Templates. Given validation can be quite important, it is best you confirm your configuration is workable in the UI first, before automating it (IMHO).
According to this discussion this seems only possible via the REST API (see e.g. this answer) and not (yet) via ARM.
I managed to get this working with an ARM template. The below link shows you how to do this using Azure Front Door as a certificate source:
https://github.com/Azure/azure-quickstart-templates/blob/master/101-front-door-custom-domain/azuredeploy.json
I drew inspiration from this for deploying a certificate from Azure Key Vault for a custom domain. Here are the relevant elements from the ARM template that I am using:
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"hubName": {
"type": "string",
"metadata": {
"description": "Name to assign to the hub. This name will prefix all resources contained in the hub."
}
},
"frontdoorName": {
"type": "string",
"metadata": {
"description": "Name to assign to the Frontdoor instance"
}
},
"frontdoorCustomDomain": {
"type": "string",
"metadata": {
"description": "The custom domain name to be applied to the provisioned Azure Frontdoor instance"
}
},
"keyVaultCertificateName": {
"type": "string",
"metadata": {
"description": "Name of the TLS certificate in the Azure KeyVault to be deployed to Azure Frontdoor for supporting TLS over a custom domain",
"assumptions": [
"Azure KeyVault containing the TLS certificate is deployed to the same resource group as the resource group where Azure Frontdoor will be deployed to",
"Azure KeyVault name is the hub name followed by '-keyvault' (refer to variable 'keyVaultName' in this template)"
]
}
},
...
},
"variables": {
"frontdoorName": "[concat(parameters('hubName'), '-', parameters('frontdoorName'))]",
"frontdoorEndpointName": "[concat(variables('frontdoorName'), '-azurefd-net')]",
"customDomainFrontdoorEndpointName": "[concat(variables('frontdoorName'), '-', replace(parameters('frontdoorCustomDomain'), '.', '-'))]",
"keyVaultName": "[concat(parameters('hubName'), '-keyvault')]",
"frontdoorHostName": "[concat(variables('frontdoorName'), '.azurefd.net')]",
...
},
"resources": [
{
"type": "Microsoft.Network/frontdoors",
"apiVersion": "2020-05-01",
"name": "[variables('frontdoorName')]",
"location": "Global",
"properties": {
"resourceState": "Enabled",
"backendPools": [...],
"healthProbeSettings": [...],
"frontendEndpoints": [
{
"id": "[concat(resourceId('Microsoft.Network/frontdoors', variables('frontdoorName')), concat('/FrontendEndpoints/', variables('frontdoorEndpointName')))]",
"name": "[variables('frontdoorEndpointName')]",
"properties": {
"hostName": "[variables('frontdoorHostName')]",
"sessionAffinityEnabledState": "Enabled",
"sessionAffinityTtlSeconds": 0,
"resourceState": "Enabled"
}
},
{
"id": "[concat(resourceId('Microsoft.Network/frontdoors', variables('frontdoorName')), concat('/FrontendEndpoints/', variables('customDomainFrontdoorEndpointName')))]",
"name": "[variables('customDomainFrontdoorEndpointName')]",
"properties": {
"hostName": "[parameters('frontdoorCustomDomain')]",
"sessionAffinityEnabledState": "Enabled",
"sessionAffinityTtlSeconds": 0,
"resourceState": "Enabled"
}
}
],
"loadBalancingSettings": [...],
"routingRules": [...],
"backendPoolsSettings": {
"enforceCertificateNameCheck": "Enabled",
"sendRecvTimeoutSeconds": 30
},
"enabledState": "Enabled",
"friendlyName": "[variables('frontdoorName')]"
}
},
{
"type": "Microsoft.Network/frontdoors/frontendEndpoints/customHttpsConfiguration",
"apiVersion": "2020-07-01",
"name": "[concat(variables('frontdoorName'), '/', variables('customDomainFrontdoorEndpointName'), '/default')]",
"dependsOn": [
"[resourceId('Microsoft.Network/frontdoors', variables('frontdoorName'))]"
],
"properties": {
"protocolType": "ServerNameIndication",
"certificateSource": "AzureKeyVault",
"minimumTlsVersion": "1.2",
"keyVaultCertificateSourceParameters": {
"secretName": "[parameters('keyVaultCertificateName')]",
"vault": {
"id": "[resourceId(resourceGroup().name, 'Microsoft.KeyVault/vaults', variables('keyVaultName'))]"
}
}
}
}
]
}
Azure Front Door classic now seems to support both managed certificates and custom certificates for custom domains. At least there are quickstart templates in the official repo from Microsoft exactly for these cases:
managed certificate
custom certificate
They both use Microsoft.Network/frontdoors/frontendEndpoints/customHttpsConfiguration subresource of the Front Door, currently with API version 2020-07-01. Only the parent subresource is documented in the templates reference, though.
The name of the customHttpsConfiguration resource is "default", so when the resource is specified as a top-level resource in the template, its complete name is something like "myfrontdoorafd/www-example-com/default".
Using Bicep (which transpiles to JSON ARM templates and which I highly recommend), the important part of the template looks like this:
param frontDoorName string
param customDomainName string
var frontEndEndpointCustomName = replace(customDomainName, '.', '-')
resource frontDoor 'Microsoft.Network/frontDoors#2020-01-01' = {
name: frontDoorName
properties: {
frontendEndpoints: [
{
name: frontEndEndpointCustomName
properties: {
hostName: customDomainName
...
}
}
...
]
...
}
...
resource frontendEndpoint 'frontendEndpoints' existing = {
name: frontEndEndpointCustomName
}
}
// This resource enables a Front Door-managed TLS certificate on the frontend.
resource customHttpsConfiguration 'Microsoft.Network/frontdoors/frontendEndpoints/customHttpsConfiguration#2020-07-01' = {
parent: frontDoor::frontendEndpoint
name: 'default'
properties: {
protocolType: 'ServerNameIndication'
certificateSource: 'FrontDoor'
frontDoorCertificateSourceParameters: {
certificateType: 'Dedicated'
}
minimumTlsVersion: '1.2'
}
}
Note that the deployment will be in progress till the certificate is actually issued and deployed to all points of presence (PoP) of Azure. This may take really long and even fail due to RequestTimeout. If you want to just start the operation and let it complete asynchronously, use e.g. the enable-https subcommand in Azure CLI. Even after the failure, the customHttpsProvisioningState is Pending and the certificate provisioning process may complete successfully.
Also note that when you have many frontend endpoints and changes happen frequently but most frontend endpoints stay unchanged, the pattern from this template cannot be generalized just by specifying multiple customHttpsConfiguration instances for multiple frontend endpoints. Such a generalization is not efficient and likely hits the rate limit of the underlying API (429 TooManyRequests) because the API is called even when the endpoint already has the HTTPS configuration.
In such a case, I was able to use nested templates and conditional deployment to deploy the customHttpsConfiguration subresource only when the frontend endpoint's property customHttpsProvisioningState has the value of Disabled. This works OK even with tens of frontend endpoints when a new frontend endpoint is added (and it should get a managed certificate). Even in deployment mode Complete, the once-applied configuration persists.

Stop Creation of Resources on Azure Subscription

I need to stop creation of all resources on my azure subscription except for:
Logic Apps
Dashboards
Solutions
the only way I can think of doing this right now is via Azure Policy, will anyone know how to write such policy?
well, you basically need to use not and anyof in combination with deny:
"if": {
"not": {
"anyOf": [
{
"field": "type",
"equals": "Microsoft.Logic/workflows"
},
{
"field": "type",
"equals": "Microsoft.OperationsManagement/solutions"
},
{
"field": "type",
"equals": "Microsoft.Portal/dashboards"
}
]
}
},
"then": {
"effect": "Deny"
}
resource types might be wrong, but I'm not sure what are you after exactly.
Policies require definitions (where the policy logic is written) and then a policy assignment (where the definition is assigned to a scope). Policy definitions can be grouped into Policy Initiatives (AKA Policy Set Definitions). These Initiatives can also be assigned to a scope. Scopes can be defined at the Resource Group level, Subscription level, or Management Group level.
Policies can be written and assigned through the portal by first creating a policy definition and then assigning it. IMO this can be a bit cumbersome when done through the portal. Or they can be deployed via ARM template. Unfortunately, the portal template deployment is not currently configured to deploy at anything other than at the resource group level (08/29/2019). But it is much easier to write and deploy via the deployment API. I use Postman to do this.
A subscription scoped (as you are describing) policy deployment can be done via PUT to the following URI.
https://management.azure.com/subscriptions/:subscriptionId/providers/Microsoft.Resources/deployments/mypolicydeployment?api-version=2019-05-01
Where :subscriptionId is Postman parameter notation for your actual Subscription ID.
You will need to obtain a bearer token to authenticate for the PUT request and that user must have permissions to deploy and assign policies. That is a whole other topic, you can learn more about that here (https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code).
Also, I supply a "Content-Type" = "application/json" header with my PUT request.
My this is my body payload for your policy.
{
"location": "westus2",
"properties": {
"mode": "Incremental",
"template": {
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"subscriptionId": {
"type": "string"
}
},
"resources": [
{
"type": "Microsoft.Authorization/policyDefinitions",
"name": "my-deny-policy",
"apiVersion": "2018-05-01",
"location": "westus2",
"properties": {
"displayName": "My Deny Policy",
"policyType": "Custom",
"description": "This policy DENYS all resource creation except, Logic Apps, Dashboards, and Solutions.",
"mode": "All",
"policyRule": {
"if": {
"not": {
"anyOf": [
{
"field": "type",
"equals": "Microsoft.Logic/workflows"
},
{
"field": "type",
"equals": "Microsoft.OperationsManagement/solutions"
},
{
"field": "type",
"equals": "Microsoft.Portal/dashboards"
}
]
}
},
"then": {
"effect": "Deny"
}
}
}
},
{
"name": "my-policy-assignment",
"type": "Microsoft.Authorization/policyAssignments",
"apiVersion": "2018-05-01",
"location": "westus2",
"identity": {
"type": "SystemAssigned"
},
"properties": {
"displayName": "My Policy Assignment",
"policyDefinitionId": "[concat('/subscriptions/', parameters('subscriptionId'), '/providers/Microsoft.Authorization/policyDefinitions/my-deny-policy')]",
"scope": "[concat('/subscriptions/', parameters('subscriptionId'), '/')]",
"notScopes": [],
"parameters": {},
"description": "This assignment contains my policy to DENY creation of all resources except logic apps, dashboards, and solutions.",
"metadata": {}
},
"dependsOn": [
"my-deny-policy"
]
}
]
},
"parameters": {
"subscriptionId": {
"value": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX"
}
}
}
}
The deployment template contains a definition containing the policy you have described, as well as a policy assignment. The policy assignment is set to "dependsOn" the policy definition. This is because the policy assignment depends on the existence of the definition to deploy properly. Otherwise, there will be a race condition that you will always lose.
Certain fields can be broken out into parameters as I have done with the subscription ID. In order to apply at another subscription scope, simply change the parameter value and make sure your bearer token is authorized for that subscription.
Where exactly you stock in creating azure policy?
Refer this doc, You can restrict/allow upon resource types
Make a Custom RBAC Role with "ACTIONS" only for these 3 you want.
Policy is OK here but it depends on the User role if he would be able to Unassign such policy from the Subscription.
To prevent user to do so:
Apply policy on level higher then subscrption (mgmt group) where user has no rights.
OR disallow user (in RBAC role) to work on Policy
Definitions & Assigments.
OR Create this Policy with Blueprint and
set ReadOnly Lock for this Bluepring Assignment.

Azure Front Door - How to add geo filtering policy?

I want to apply a geo filter to azure front door for countries that are outside of the US.
I've applied a waf policy (following the microsoft docs), but I'm not getting the desired result. All traffic appears to be denied. If I try a different country code, all traffic seems to be allowed.
Here's an example of a deny policy I'm trying to get working. If I apply this rule and test via locabrowser, the traffic is allowed.
I'm testing this theory by using locabrowser to simulate traffic from different locations.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"frontdoorwebapplicationfirewallpolicies_DenyChinaWafPolicy_name": {
"defaultValue": "DenyChinaWafPolicy",
"type": "String"
}
},
"variables": {},
"resources": [
{
"type": "Microsoft.Network/frontdoorwebapplicationfirewallpolicies",
"apiVersion": "2018-08-01",
"name": "[parameters('frontdoorwebapplicationfirewallpolicies_DenyChinaWafPolicy_name')]",
"location": "Global",
"properties": {
"policySettings": {
"enabledState": "Enabled",
"mode": "Prevention"
},
"customRules": {
"rules": [
{
"name": "geoFilterRule",
"priority": 1,
"ruleType": "MatchRule",
"rateLimitDurationInMinutes": 1,
"rateLimitThreshold": 0,
"matchConditions": [
{
"matchVariable": "RemoteAddr",
"operator": "GeoMatch",
"negateCondition": false,
"matchValue": [
"CH"
]
}
],
"action": "Block"
}
]
},
"managedRules": {
"ruleSets": []
}
}
}
]
}
Geo-filtering in AFD is currently broken. It includes all the country instead of specific location. Fix is made and will be released soon. Will update here once the fix is updated.
This also does not work for me. Whatever I set the action to allow or block with matchVariable": "RemoteAddr" and "operator": "GeoMatch", It seems that this policy did not rely on the "matchValue", just works depending on the action. It seems that Geo filtering with WAF is still not available.
Please note that the Azure web application firewall (WAF) for Azure Front Door is currently in public preview.
You could give your voices or vote these feedback1 and feedback2 about geo-filtering.

Configure programmatic deployment for Azure Bing maps

I'm trying to add BingMaps to our resource template.
this is the template so far:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"mapsName": {
"type": "string"
}
},
"variables": {
"location": "[resourceGroup().location]"
},
"resources": [
{
"apiVersion": "2015-07-02",
"type": "Microsoft.BingMaps/mapApis",
"name": "[parameters('mapsName')]",
"location": "westus",
"plan": {
"publisher": "bingmaps",
"product": "mapapis",
"name": "myMapsTest",
"promotionCode": null
},
"properties": {
"provisioningState": "Succeeded"
}
}
],
"outputs": {
}
}
It gives this error message:
New-AzureRmResourceGroupDeployment : 14:22:50 - Resource
Microsoft.BingMaps/mapApis 'myMapsName' failed with message 'User
failed validation to purchase resources. Error message: 'Legal terms
have not been accepted for this item on this subscription. To accept
legal terms, please go to the Azure portal
(http://go.microsoft.com/fwlink/?LinkId=534873) and configure
programmatic deployment for the Marketplace item or create it there
for the first time''
How can I configure programmatic deployment for Azure Bing maps?
The current workaround is: create the marketplace item once under the very same subscription you are going to use for the programmatic deployment. It worked me like charm.. (although I am not happy this interactive hocus pocus at all)
The supposed correct solution is not working yet (issue), but hopefully will. See below:
Seems to be an Azure Subscription issue - what type of subscription do you have (pay as you go, free, EA?).
What location did you try to deploy to?
Also - are you able to provision "Bing Maps API for Enterprise" offering for the marketplace?

Resources