Sorry for this basic topic but I am pretty confused about azure Management Groups and policy.
I have a production subscription, on which I would like to deny all the manual creation of resource and allow only the creation the resource as code.
Which mean, if I try to create or change a resource from the portal, to get an error, but if I want to create the resource with terraform or bicep, to be able to do so with the terminal.
So what I did, in my Management Groups I added a child group and assigned the subscription. On the child group, I created the policy to deny all the Microsoft.* as follow:
{
"mode": "All",
"policyRule": {
"if": {
"field": "type",
"like": "Microsoft.*"
},
"then": {
"effect": "deny"
}
}
}
This works just fine, but how can I still be able to create resource with terraform or bicep using the terminal?
Or maybe somebody can advice me on a better approach on how to solve this problem please?
Thank you very much
If you apply this policy, it will be valid for service principals as well.
A better approach would be to restrict the RBACs of users(like Reader) and use only a Service Principal to deploy resource to Azure. That's a more simple approach.
Related
I am deploying the Azure policy for the Recommended Tags that need to be applied when anyone creates the new VM.
I found one in-built policy: Require a tag on resources
But when I deployed, it will be applied to all the resources and I need a policy for only VM resources.
Also how I can use more than one tag in a single policy?
In your policy rule, you must indicate that the policy is just for VMs
For example:
...
"policyRule": {
"if": {
"field": "type",
"in": [
"Microsoft.Compute/virtualMachines",
"Microsoft.ClassicCompute/virtualMachines"
]
},
"then": {
...
}
}
...
Hope this helps!
I am trying to deploy my logic app to multiple environments using CI/CD pipeline. I am getting an error -The client 'guid' with object id ''guid' ' has permission to perform action 'Microsoft.Logic/workflows/write' on scope 'Test Resource group'; however, it does not have permission to perform action 'Microsoft.Logic/integrationAccounts/join/action' on the linked scope(s) 'Development Resource group integration account' or the linked scope(s) are invalid.
Creating another integration account for test resource group doesnt come under free tier. Is there a way to share integration account across multiple resource groups
Not sure what the permissions issue is but you might need to give more information around this.
But try the below first in your pipeline. Works for us with 3 different resource groups and two integration accounts
"parameters": {
"IntegrationAccountName": {
"type": "string",
"minLength": 1,
"defaultValue": "inter-account-name"
},
"Environment": {
"type": "string",
"minLength": 1,
"defaultValue": "dev"
}
},
"variables": {
"resourceGroupName": "[if(equals(parameters('Environment'), 'prd'),'rg-resources-production','rg-resources-staging')]",
"LogicAppIntegrationAccount": "[concat('/subscriptions/3fxxx4de-xxxx-xxxx-xxxx-88ccxxxfbab4/resourceGroups/',variables('resourceGroupName'),'/providers/Microsoft.Logic/integrationAccounts/',parameters('IntegrationAccount'))]",
},
In the above sample, we had two different integration accounts one for testing and one for production. This is why I have set the integration account name as a parameter as it changes between environments.
I have created a variable "resourceGroupName" this is important because this url is setting up a direct link to the integration account which is stored in a known resource group. In this sample I have included an if statement using the value set at the "environment" parameter. This helps select which resource group is going to be used.
I then create another variable which stores the new URL. Replace the subscription guid with your own: 3fxxx4de-xxxx-xxxx-xxxx-88ccxxxfbab4.
Once that is created you need to change the ARM template to use the variable you just created. To set it,place in the properties object.
"properties": {
"state": "Enabled",
"integrationAccount": {
"id": "[variables('LogicAppIntegrationAccount')]"
},
So for you pipeline it should just be a normal arm template but with these two parameters above being set.
Let me know if you have more questions around this.
I want to stop creation of Log Analytics workspaces, what is the best way to achieve this? can you do this via azure policies, if so how?
thank you in advance,
Kelly
AFAIK, the best possible way to restrict creating any resources is using azure policies. Below azure policy will help you in stopping the creation of log analytics workspace in your subscription.
{
"properties": {
"displayName": "Deny creating Log analytics",
"description": "This policy denies creation of log analytics workspace.",
"parameters": {
},
"policyRule": {
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.OperationalInsights/workspaces"
}
]
},
"then": {
"effect": "deny"
}
}
}
}
It is also interesting to note that with the introduction of the new access control mode "Require Workspace Permissions", users can only see logs for resources that they have the correct privileges to. Therefore allowing teams to utilize a centralized Log Analytics workspace for all their logging needs
Is it possible to overwrite Azure resource values with Azure policy values? I am trying to fix the VM size/sku. I created the below Policy with an append effect which fails VM creation as it cannot overwrite the default/given VM size/sku.
{
"if": {
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
"then": {
"effect": "append",
"details": [{
"field": "Microsoft.Compute/virtualMachines/sku.name",
"value": "Standard_D4_v3"
}
]
}
}
No, it is not possible to overwrite a resource value using an ARM policy append effect. The behavior you are experiencing is by design as described here.
Since a VM's SKU is a single value vs. a collection/array of values, the only action you could hope to take is to overwrite the original value. But, as you are seeing, an ARM policy will revert to the deny effect instead in this case.
I have resource group "MyResources", that contains 4 resources:
AppService - myserver,
AppServicePlan - MyServerWestEuFarm,
ApplicationInsights - myserver-insights,
StoregeAccount - myserverstorage
When I try to move them to another subscription, I get error message:
Cannot move resources because some site(s) are hosted by other resource group(s) but located in resource group 'MyResources'. The list of sites and corresponding hosting resource groups: myserver:vyvojari.sk'. This may be a result of prior move operations. Move the site(s) back to respective hosting resource groups and try again. (Code: BadRequest, Target: Microsoft.Web/serverFarms)
What does that mean? Especially myserver:vyvojari.sk is confusing.
"vyvojari.sk" is another resource group and it may be possible that I've created myserver appservice in that resource group in the past and moved. So what?
In the resource explorer for the myserver AppService I see:
{
"id": "/subscriptions/xxxxxxxx-d9e0-4769-8440-8cd7968bf94d/resourceGroups/MyResources/providers/Microsoft.Web/sites/myserver",
"name": "myserver",
"type": "Microsoft.Web/sites",
"kind": "app",
"location": "West Europe",
"properties": {
"name": "myserver",
"state": "Running",
"hostNames": [
"myserver.azurewebsites.net"
],
"webSpace": "vyvojari.sk-WestEuropewebspace",
"selfLink": "https://waws-prod-am2-071.api.azurewebsites.windows.net/subscriptions/xxxxxxxx-d9e0-4769-8440-8cd7968bf94d/webspaces/vyvojari.sk-WestEuropewebspace/site/myserver",
"repositorySiteName": "myserver",
But what is webspace and selflink? How can I change it?
This may be too obvious but I think, they want you to move back the 'myserver' resource to the 'vyvojari.sk' resource group. Once that is done, do the subscription operation.
It is possible that although, myserver is in the current resource (you have said that you may have moved it here) is still 'hosted' in that vyvojari resource group despite being part of the current group. By this logic, looks like moving it back to vyvojari should allow you do your subscription related task.
You need to consider the following limitations when moving the App Services to another Resource Group/Subscription.
When working with App Service apps, you cannot move only an App Service plan. To move App Service apps, your options are:
Move the App Service plan and all other App Service resources in that
resource group to a new resource group that does not already have App
Service resources. This requirement means you must move even the App
Service resources that are not associated with the App Service plan.
Move the apps to a different resource group, but keep all App Service
plans in the original resource group.
The App Service plan does not need to reside in the same resource group as the app for the app to function correctly.
For more details about limitations, refer to this documentation. You will be able to move the resources only if all the requirements/conditions are met.
You should have moved the resources back to original resource group (as per the error, myResources), migrate to different subscription, and than re-segment them into respected resource groups, as needed.