Create a Resource Lock Utility to Prevent modification to T3 resources

[lisamurphy-msft]

Benefit/Result/Outcome

As a MissionLZ admistrator or system owner, I want the ability to apply resource locks on the T3 resource groups to prevent system integrators from altering the networking or other such resource allocations and incurring un-vetted expenses.

Description

Resource locking is something that can be applied at the resource group level by the account owner to prevent editing or deletion or adding of resources. Having a utility included to guide the system administrator in facilitating resource locks to prevent this potential use case defined in #305 as denoted by @sstjean would be a useful implementation to achieve the desired effect.

As per @sstjean :
"a VNet is created with specific subnets as configured by the deployment/operations team. The Tier 3 subscription can them be "handed over" to the workload owner to deploy necessary resources which will attach to the created subnets. The forced-tunneling routes are configured in the RG created by MLZ and should be controlled by the Ops team and not the Tier 3 workload owner. Giving the workload owner OWNER permissions to the Tier 3 sub now allows the Tier 3 owner the ability to change the forced tunneling or CIDR ranges outside of the operations team's control. By putting a READ lock on the networking resources, the Tier 3 owner can attach new resources to the subnet but cannot change the subnet or routing configuration."

Acceptance Criteria

• Update the utilities with enhanced guidance with samples to provide resource locks to T3 Resources.
• Provide documentation on usage and potential configurable options.

[brooke-hamilton]

Recommend adding a parameter to the T3 example that will set resource locks.

[glennmusa]

one could run az deployment group create with a resource group scoped template that locks the resource group like:

resource createRgLock 'Microsoft.Authorization/locks@2016-09-01' = {
  name: 'rgLock'
  properties: {
    level: 'CanNotDelete'
    notes: 'Resource group should not be deleted.'
  }
}

https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/scope-extension-resources#apply-at-deployment-scope

[brooke-hamilton]

I'm closing this issue for now, but we can re-open if needed.

We do not want to issue resource locks for a resource group until a deployment is fully configured. We can't be sure that our initial configuration will be the final configuration for a particular customer, especially for T3 resources, which will probably have additional resources deployed after or along with the T3 deployment.