Microsoft.Authorization Namespace Bicep Modules

[ahmadabdalla]

Uplifted existing and created new bicep modules for the Microsoft.Authorization Namespace.

Modules:

• Policy Set Definitions (1 deploy.bicep, 2 nested) + Pipeline + Readme
• Policy Definitions (1 deploy.bicep, 2 nested) + Pipeline + Readme
• Policy Assignments (1 deploy.bicep, 3 nested) + Pipeline + Readme
• Policy Exemptions (1 deploy.bicep, 3 nested) + Pipeline + Readme
• Role Definitions (1 deploy.bicep, 3 nested) + Pipeline + Readme
• Role Assignments (1 deploy.bicep, 3 nested) + Pipeline + Readme <<< New Method, changes existing >>>

Design:

• All modules deploy at the 'managementGroup' scope, and then access different scopes based on parameters:
• Support for MG, SUB and Resource Group Scopes.
• All nested templates (Scopes) are also deployable in isolation. Allowing to test individual templates the same method to the 'deploy.bicep.
• The Pipelines for the 'Microsoft.Authorization' name space points to the 'nested_sub' bicep templates rather than the 'deploy.bicep'. But that is only for 'DEPLOYMENT / TEST DEPLOYMENT'. All other testing and publishing still happens on the 'deploy.bicep'.
  

Parameters:

• managementGroupId ==> deploys at Management Group Level
• subscriptionId ==> deploys at Subscription Level
• resourceGroupId + 'subscriptionId' ==> deploys at Resource Group Level

Pester Updates;

• [-] [roleAssignments] Variable names should be camel-cased (no dashes or underscores and must start with lower-case letter) 73ms (70ms|3ms)
  • Removed condition that prevents variables from using ' _ '. To align with the Bicep variables model (var myVar_var)
• [-] [roleDefinitions] All resources that have a Location property should refer to the Location parameter 'parameters('Location')' 166ms (162ms|3ms)
  • Added an elseif condition that enforces the use of Parameter - Location for deployments that support it. The reason is that modules do not support custom locations. See issue

Testing:

• All modules have been tested in the fork as the Service Principal can perform Management Group Deployments.
• Attaching screenshots.
  Role Definitions:
  

Role Assignments

Policy Assigments

Policy Definitions

Policy Set Definitions

Policy Exemptions

All

Hot Topic

• Role Assignments Module has been simplified to only target a Role Definition and a Principal ID, aligning to the Documentation of the actual module. The existing approach (multi role, multi principals) although is useful, is custom in nature and can be split into its own module that leverages the base simple module.
• Requires a meeting to discuss the details and rationale. and ensure everyone is aligned.

Type of Change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• My corresponding pipelines / checks run clean and green without any errors or warnings
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (readme)
• I did format my code

[ahmadabdalla]

@MrMCake @segraef @eriqua @rahalan . Recent updates:

• All modules / nested modules are deployable in isolation for the 'Microsoft.Authorization. namespace.
• As we've discussed yesterday, the pipelines point to the nested_<resourceType>_sub'.bicep . This allows us to successfully deploy and complete the pipeline stages, thus enabling testing and publishing. Testing and publishing still happens on the 'deploy.bicep' level.
• The hot topic for 'Role Assignments' is still open. Would be great if we could talk about it soon and align.