You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Appending the Management group ID to the role name can cause confusion, especially when using PIM to activate roles because when you see the management group in the name it's easy to assume this is the scope of the role assignment, not the role definition.
Most Azure admins don't need to know or care where a role is defined, and may not be aware that role definitions even need a scope if they are just familiar with using built-in roles.
I understand the reasoning behind this to ensure the name is unique within the tenant, however many environments are likely only to have a single architecture within a tenant, or if there are multiple architectures it's likely there's only one production with the others for testing.
Even with multiple production architecture definitions in a tenant, it may not be desirable to use the Management Group ID as the suffix, instead it could be helpful to have this as something meaningful such as an environment name, or business unit, which may not cleanly align with the management group ID.
Instead of always appending the management group ID can this be parameterized? E.g. if using a new provider variable like custom_role_name_suffix the behavior could be as follows:
If null: Use management group ID for the suffix
Preserves existing behavior so no breaking changes
Guarantees global uniqueness without user's having to think about names
If empty string: Do not set any suffix, role name is set exactly as per the definition
Allows suffixes to be skipped where there's a single architecture in the tenant
User's responsibility not to create multiple role definitions with the same name within the tenant
If non empty string: Use the suffix as provided
Allows role definitions in separate environments to be suffixed with a user defined naming convention
User's responsibility not to create multiple role definitions with the same name within the tenant
Appending the Management group ID to the role name can cause confusion, especially when using PIM to activate roles because when you see the management group in the name it's easy to assume this is the scope of the role assignment, not the role definition.
Most Azure admins don't need to know or care where a role is defined, and may not be aware that role definitions even need a scope if they are just familiar with using built-in roles.
I understand the reasoning behind this to ensure the name is unique within the tenant, however many environments are likely only to have a single architecture within a tenant, or if there are multiple architectures it's likely there's only one production with the others for testing.
Even with multiple production architecture definitions in a tenant, it may not be desirable to use the Management Group ID as the suffix, instead it could be helpful to have this as something meaningful such as an environment name, or business unit, which may not cleanly align with the management group ID.
Instead of always appending the management group ID can this be parameterized? E.g. if using a new provider variable like
custom_role_name_suffix
the behavior could be as follows:alzlib/deployment/managementgroup.go
Line 546 in 8636139
The text was updated successfully, but these errors were encountered: