root_id variable limited to 10 characters

[Benj13]

Versions

terraform: 1.1.3

azure provider: 2.92.0

module: 1.1.1

Description

In our implementation of enterprise scale we are using a root management group ID that is more than 10 characters long. The variables.tf of the module limits that length to 10 characters but the limit set by Azure is actually 90 characters long.

I understand that an ID shouldn't be as long as 90 characters but could the limit of 10 be increased to 20 or 30 characters?

Steps to Reproduce

Set the variable root_id to 11 or more characters.

[krowlandson]

Hi @Benj13... thank you for raising this request.

The limit of 10 characters is implemented to reduce the risk of creating other resource names which are too long. This is because each resource type in Azure has a different name length limit, and we use the root_id value as a prefix for most resources created as part of Enterprise-scale.

This limit was originally at 5 characters, and I worked with the team to increase this to the current value of 10:

• Update root prefix allowed length to 10 characters #426

Due to the risk associated with increasing this further, I don't believe this is something we would want to implement but I will move this issue to the upstream Azure/Enterprise-Scale repository. If it gets approved there, we can implement this consistently across each implementation of the ES landing zones, including this module.

[krowlandson]

@Benj13... as an aside regarding the following comment in your issue:

In our implementation of enterprise scale we are using a root management group ID that is more than 10 characters long.

If you have already implemented Enterprise-Scale using another approach (i.e. not the caf-enterprise-scale module), are you aware of the need to import all resources into Terraform state for those you do not wish to re-create?

[jtracey93]

Thanks @krowlandson. And Hi @Benj13, thanks for raising this.

As @krowlandson has commented, we have indeed limited this for a reason to help us not run out of characters for naming resources as part of an ESLZ deployment.

Also linking this to: #674 (and may end up closing this and rolling it up into this issue for ease of tracking).

I'll let you reply back to @krowlandson's questions above. And if you can share any info as to why more than 10 characters is required that would be great to hear to help us understand the "why" 👍

Thanks

Jack

[Benj13]

Hi @krowlandson, @jtracey93, thanks for your quick replies, I understand the purpose of the limitation now.

As for @krowlandson question, we are already using the Enterprise Scale terraform module but an old version (0.0.8) and are working on upgrading it to the latest version so we already have the resources in terraform.

And for the why we need more than 10 characters, we are using the module mainly to define the management group structure and the policy definitions/assignments. The resources have been deployed separately with terraform as the management, connectivity and identity modules were not available at the time we started.

We work today with a local copy of all the policy definitions and assignments in our repo and we worked around the root_id by replacing ${root_scope_resource_id} by the path of our root management group in our local copy of the policy assignments. Now we would like to rely as much as possible on the standard definitions/assignments to be able to follow the updates of the module but our root management group ID is more than 10 characters and the terraform plan fails, which is why I raised the issue.

So I assume that our options are either to continue with a local copy of the policy definitions and assignments or deploy a new management group structure with a root ID that is less than 10 characters.

[jtracey93]

Hi @Benj13,

No worries at all 👍

From my understanding (@krowlandson keep me honest) I believe the 2 options you have listed out are correct.

If this is the case I will close this issue, if you are happy with it and capture it as evidence for our naming standards issue in #674 👍

@krowlandson can you confirm @Benj13's options are correct here please? 🙂

[Benj13]

@jtracey93, thanks for your insight on the options, we've decided to go with a new management group structure that will comply with the restrictions on root_id so we can avoid managing a copy of the policy definitions and assignments.

I'm curious to know if @krowlandson think of other options, but the issue can be closed. Thanks again for the quick replies on the topic :)

[jtracey93]

Thanks @Benj13, I think that's a very sensible call (and probably the one I would of taken).

I'll close this out as suggested. But please feel free to raise an issue on this repo or the terraform module repo if you need any further assistance 👍👍