Use of ignore_changes via advanced block

[MCrank]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Versions

terraform: Terraform v1.3.7 on windows_amd64

azure provider: AzureRM v3.38.0

module: v3.1.2

Description

First off THANK you for this awesome module. I have watched the youtube videos and been living in the wiki for the past several weeks learning the ins and outs of getting this up and running.
Second, I chose the bug issue as it seemed the most appropriate but maybe this is not a bug but possibly a feature request or more so maybe just a question on functionality so sorry if this is not the appropriate place.

We have policy in place that assigns a created tag to Resource Groups and resources that support them. Subsequent runs of terraform obviously do not track that since it was applied via policy and terraform wants to remove the tag for previously created tags. It looks the lifecycle --> ignore_changes option is my go to fix to get around this.

Since this may not look like there is a fix anytime soon in the azurerm provider, I am wondering is it possible to leverage the lifcycle block in the advanced block for custom settings? I gave it a good old college try but I think that maybe this is not supported at this point due to the error I received.

Describe the bug

Tags modified outside my Terraform state are flagged for removal because they are applied as policy. I have searched around the issues here and found several mentions that seemed to be related to other resource problems. I think it was on here that perhaps this should be handled at the provider level, so I spent quite a bit of time searching around there as well.

I found some posts regarding the AWS provider, and it looks like it was implemented there, or at least a defult_tags option at the provider level. I did find several posts on the azurerm provider github and looks like some form of functionality, perhaps the tag_keys_to_ignore flag, may be included in the v4 milestone based on this issue: hashicorp/terraform-provider-azurerm#13776

Steps to Reproduce

1. Deploy the CAF-ES in some form that includes a resource
2. Once deployed add a created tag, or any tag other than the ones provide via TF to simulate policy or some other automated tag addition.
3. Re-run a plan on the CAF-ES Terraform configuration. The resource(s) that had tags added outside the TF will be listed as changes since the tag is not managed by TF

Screenshots

Azure management RG

TF Plan showing management RG group

Here is my attempt at using the advanced block - Seem to be getting a linting error here so I tried with an = which I didn't think would work and didn't. But the advanced block documentation is empty on the wiki for now so I thought I would ask out here if there was maybe something I am missing of if it is just not possible at this time?

Results of running plan with lifecycle block with =

Additional context

It might be nice, if possible, to have something at a global module level that you could add to ignore tags on resources that support them. I know that is a generic type of question as what I gather tags on the surface don't seem too bad but based off what I have been reading, at least in the azure spaces there is quite the cobwebs under the covers with not all APIs etc. doing things the same in regard to tags and many resources do tags different etc.

It seems like TAGs are the main culprit when it comes to the need for ignore_changes. Hoping there is a way to implement this as a workaround here in the module even if at the advanced block level.

Thanks so much for any help

[krowlandson]

An interesting scenario, thank you for the ask @MCrank.

As I'm sure you already understand, providing just this one option wouldn't be too big an ask but we also need to consider what other exceptions other customers are likely to ask for their own scenarios.

I think I understand the rationale behind why you are doing this, but are you aware that all resources in Azure support extraction of a creation timestamp from the resource properties? The following blog gives a nice overview of how to do this:
https://www.azureblue.io/get-azure-resource-creation-timestamp/

If that's not sufficient for your use-case (and it must be stored in a tag) then we have a couple of options as the module supports tags being applied at the module, "sub-module", and individual resource scopes.

Depending on how granular and accurate you want to set these values, will determine how complex this will be to implement.

This would allow you to either statically assign creation timestamps to the resources, or you could use the time_static resource to dynamically generate one or more static timestamps (as needed) which can then be applied to your resources at creation. This should then prevent the policy from kicking in as the resources already have a valid tag applied at creation.

Please let me know if this helps?

[MCrank]

@krowlandson Thanks for such a timely reply. I'll be honest I had not seen the time_static option as I initially was not looking to do the timestamp tagging in TF. That looks like it actually might be an option. I was aware of the azure resource creation, but it seems a little clunky in our use case. I wish that was made available in the portal and not sure why it is not, atleast to my knowledge. While we try to do as little as possible actually in the portal, I think it is a nice and quick feature to just have the tag as well right there in your face without having to look elsewhere etc.

Let me poke around with the time_static provider and see how that works. In the end the Policy is only writing the tag if it doesn't exist so if we can populate those in the TF when we create them, I think this problem might be solved. Going to kick the tires on this right now and will let you know.

[MCrank]

@krowlandson Using the time_static provider seems to be working like a champ. But I may have discovered a bug. I set the value at the root module in the default_tags section which seems to have deployed the tags as expected down to all of the resources, or at least the ones I am deploying with the exception of the Azure Firewall Policy. It looks like it is only excepting the tags from the custom settings otherwise it sets it to null while many others are using the local.tags.

Not sure if this is by design for the Firewall policy?

https://github.com/Azure/terraform-azurerm-caf-enterprise-scale/blob/main/modules/connectivity/locals.tf#L1058

Would you like a separate bug ticket if this is actually a bug?

[krowlandson]

@MCrank I believe this was due to the documented constraints around PATCH operations.

Azure IP Groups and Azure Firewall Policies don't support PATCH operations, which means they don't support updating tags through the portal. Instead, use the update commands for those resources. For example, you can update tags for an IP group with the az network ip-group update command.

I can look into this again to see whether this actually causes issues when managing tags through Terraform.

If not, we can get the "default" tags added to these resource too.

[krowlandson]

Would you like a separate bug ticket if this is actually a bug?

Happy to track via this issue 👍🏻