I'm not too familiar with azure blueprints but I have a task to update an existing blueprint definition. This involves adding a couple of artifacts and a new resource group. I have a couple of questions about this process:
If the blueprint definition is updated as a result, does it affect the existing blueprint assignments?
The azure documentation strictly talks about blueprints and does not mention the affect on resources as a result of updates, is there a risk in destroying resources as a result of updating a blueprint?
This documentation provides answers to your questions -
If the parameters of the policy assignment are changed, the existing assignment is updated.
If the definition of the policy assignment is changed, a new policy assignment is created. Policy assignments previously deployed are left in place.
If the policy assignment artifact is removed from the blueprint, deployed policy assignments are left in place.
Related
Azure Policy can be used to define conventions that, when Policy Enforcement is enabled, will prevent non-compliant resources from being created.
In scenarios where non-compliant resources need to be exempted this leads to having to coordinate several steps:
Disable policy Enforcement
Create the non-compliant resource
Add the exemption for the non-compliant resource to the Policy Assignment
Re-enable Enforcement
Review if any unexpected changes occurred during the period of time Enforcement was disabled -- and how to bring things back to compliance
While the above is acceptable, I'm curious if there is an ability to simultaneously create the non-compliant resource and the exemption without the need to coordinate other steps and create the chance for other issues to be introduced.
Is there a way to create a resource and an policy assignment exemption for it simultaneously? Is this potentially in a preview or private preview feature?
From my experience a resource needs to exist before it can be included in an exemption. However, these docs confirm that exemptions do work on the hierarchy in Azure. This means that you could in steps create a resourcegroup to hold your non-compliant resources, then create the exemption with the scope of that resourcegroup and then create the non-compliant resources.
It sounds like you are looking for an automated solution.
I have not done this or seen anyone else do this - still unsure of your use case. Why deploy a resource that needs to be exempted automatically?
Anyway, you might have a chance of achieving this with:
Blueprints: https://learn.microsoft.com/en-us/azure/governance/blueprints/overview
Manually executing a PowerShell script: https://learn.microsoft.com/en-us/cli/azure/policy/exemption?view=azure-cli-latest#az-policy-exemption-create (or API).
IaC adding this to your ARM template https://learn.microsoft.com/en-us/azure/templates/microsoft.authorization/policyexemptions?pivots=deployment-language-arm-template
Policy using Modify or DeployIfNotExists using https://learn.microsoft.com/en-us/azure/templates/microsoft.authorization/policyexemptions?pivots=deployment-language-arm-template
I am using Terraform for creating resources within Azure and attaching current time-stamp for enforcing unique names for resources like storage account, key vault etc in the .tf file.
Problem is, for existing resources, when you expect Terraform apply to do nothing, these resources are being destroyed and recreated since the time-stamp has changed between last execution and the current one!
Wondering what's the best strategy to enforce uniqueness, dynamically.
The initial texts for these resources come from Azure Pipeline variables and I'm appending current time-stamp for adding uniqueness.
According to Cloud Adoption framework you could define a convention like the one shown below.
Terraform example
name = "${local.prefix}-${var.location}-app-plan"
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming
I also suggest you to look the naming azure plugin which can help you create unique names across resources
https://registry.terraform.io/modules/Azure/naming/azurerm/latest
I am creating an Azure policy to enforce some naming conventions. I want to enforce this policy only for any new resources being created. I am planning to use Deny as an Effect.
Will the Deny effect block the existing resources being re-provisioned?
Is there any way to implement this without impacting the re-provisioning of old resources? As per the document here, it says updating will be prohibited.
As mentioned in the link that you provided the policy is applied "When creating or updating a matched resource".
However, you can enforce a policy per resource group.
So, if you have the possiblity to have all the existing resources in one resource group and all the new resources in a second resource group. Then you can get around it by applying the policy only to the second resource group.
We manage an Azure subscription operated by several countries. Each of them is quite independant about they can do (create/edit/remove resources). A guide of good practices has been sent to them, but we (security team) would like to ensure a set of NSG is systematically applied for every new subnet/vnet created.
Giving a look to Azure Triggers, I am not sure that subnet creation belongs to the auditable events. I also was told to give a look to Azure policy, but once again I am not sure this will match our expectations which are : For every new vnet/subnet, automatically apply a set of predefined NSG.
Do you have any idea about a solution for our need ?
I have done work like this in the past (not this exact issue) and the way I solved it was with an Azure Function that walked the subscription and looked for these kinds of issues. You could have the code run as a Managed Identity with Reader rights on the subscription to report issues, or as a Contributor to update the setting. Here's some code that shows how you could do this with PowerShell https://github.com/Azure/azure-policy/tree/master/samples/Network/enforce-nsg-on-subnet
You could consider using a Policy that has a DeployIfNotExists Action, to deploy an ARM template that contains all the data for the NSG. https://learn.microsoft.com/en-us/azure/governance/policy/samples/pattern-deploy-resources
You can get the ARM template by creating the NSG and getting the template:
GettingNSGTemplate
Note also that creating a subnet is audited, you can see it in the Activity Log for the VNet. See the screen shot.
AddingASubnet
I have an Azure terraform configuration. It sets up resource groups, key vaults, passwords, etc ...
When I destroy it terraform does the same in reverse - deleting secrets, access polices, key vaults and the last are resource groups.
But, if the resource groups are to be destroyed anyway, it makes sense just to destroy them first - all the child resources will be deleted automatically. But the azurerm provider does not do it this way.
What am I missing here? And if my understanding is correct, is there a way to implement it (without altering the provider, that is) ?
In Terraform's model, each resource is distinct. Although Terraform can see the dependencies you've defined or implied between them, it doesn't actually understand that e.g. a key vault is a child object of a resource group and so the key vault might be deleted as a side-effect of deleting the resource group.
With that said, unfortunately there is no built-in way in Terraform today to achieve the result you are looking for.
A manual approximation of the idea would be to use terraform state rm to tell Terraform to "forget" about each of the objects (that is, they will still exist in Azure but Terraform will have no record of them) that will eventually be destroyed as a side-effect of deleting the resource group anyway, and then running terraform destroy will only delete the resource group, because Terraform will believe that none of the other objects exist yet anyway. However, that is of course a very manual approach that, without some careful scripting, would likely take longer than just letting the Azure provider work through all of the objects in dependency order.
There is an exploratory issue in the Terraform repository that covers this use-case (disclaimer: I'm the author of that issue), but the Terraform team isn't actively working on that at the time I write this, because efforts are focused elsewhere. The current set of use-cases captured there doesn't quite capture your idea here of having Terraform recognize when it can skip certain destroy operations, so you might choose to share some details about your use-case on that issue to help inform potential future design efforts.
Terraform is built this way, it wouldn't traverse the graph and understand that if the resource group is deleted - anything inside resource group will be deleted as well. which isn't even true in some cases. So I would say it doesn't make sense to do that.
Only real time when this is annoying - when you are testing. for that time you can create a script that would initiate resource group deletion and clear local state, for example