Add deployment scripts and configuration for Sovereign Cloud

[Jan Egil Ring (janegilring)]

This pull request introduces a new automated lab deployment flow for Azure Sovereign Cloud MicroHack environments, focusing on per-participant resource group isolation and precise role-based access control (RBAC). The changes include new deployment scripts, infrastructure-as-code templates, and configuration files to streamline and secure lab provisioning, ensuring each participant receives the necessary permissions and resources.

Lab deployment automation and configuration:

• Added deploy-lab.ps1, a PowerShell script that orchestrates lab resource deployment at the subscription or resource group level, validates parameters, sets preferred locations, registers required resource providers, and assigns RBAC roles to participants.
• Introduced lab-defaults.json to define default lab parameters such as deployment type, number of labs per subscription, preferred Azure regions, and estimated daily costs.

RBAC and infrastructure provisioning:

• Added main.bicep to assign subscription-scoped RBAC roles (Security Reader, Resource Policy Contributor) to lab participants and invoke a module for resource-group-scoped RBAC, ensuring participants have appropriate permissions.
• Added rg-rbac.bicep module to assign resource-group-scoped roles (Key Vault Administrator, Storage Account Contributor) to participants, supplementing the Owner role already granted.

Resource provider registration:

• Added resource-providers.ps1, a script to register all required Azure resource providers for the Sovereign Cloud MicroHack, ensuring all necessary services are available before deployment.

[Marco Weber (qxsch)]

Jan Egil Ring (@janegilring) awsome contribution: does it have to be subscription level deployment?

[Marco Weber (qxsch)]

Dmitriy Nekrasov (@nekdima) please have a look at this

[Marco Weber (qxsch)]

Jan Egil Ring (@janegilring) can you remove the 99-MicroHack-Template/labautomation/main.bicep from the template folder?

[Marco Weber (qxsch)]

Dmitriy Nekrasov (@nekdima) please review

[Dmitriy Nekrasov (nekdima)]

Thanks Jan Egil Ring (@janegilring). Deterministic role-assignment names are the right call, and re-runs are already safe in the two RG modes.

The gap is the full event model: 2–100 participants, one or many subscriptions, and shared Azure Local sized to the group.

1. Subscription mode is broken

main.bicep deploys rg-rbac.bicep at resourceGroup(resourceGroupName), but the platform passes an empty name in subscription mode. Create a deterministic RG there, or make the module conditional. resourcegroup-with-subscriptionowner is unvalidated too.

Resource Group Name is also inverted: emitted in the RG modes, where the platform reserves and drops it, and omitted in subscription mode, where the script should emit it.

2. Shared LocalBox and ArcBox access is manual

Still a portal step against LabUsers: LocalBox RG Reader plus Azure Stack HCI VM Contributor, ArcBox RG Reader plus constrained User Access Administrator.

1. The script gets individual object IDs. Assign per user, or can the platform supply a group principal?
2. If the shared environment is in another subscription, how is the deploying SP authorized? The contract gives it Owner on the participant subscription only, and forbids Set-AzContext.

Both config channels are closed: the parameter block must match exactly, and lab-defaults-schema.json sets additionalProperties: false. A sidecar file read by the script is the only no-platform-change option I see. Marco Weber (@qxsch), better idea?

3. LocalBox preparation is manual

Not automated: expanding UserStorage_1 and staging the image into it, removing UserStorage_2, creating localbox-vm-lnet-vlan200. Staging alone is ~2.5 h.

deploy-localbox.ps1 also prompts interactively and submits a timestamped --no-wait deployment, so re-runs start fresh instead of converging.

NIC creation can stay in the exercise; prep only has to guarantee the logical network.

4. Participants-per-LocalBox should be a parameter

LocalBox is ~100-110 USD/day and 4-6 h to provision, so density belongs next to labsPerSubscription: 1, 2 or 4 per instance. At 100 participants that is 25 instances or 100.

Instance count is participants ÷ density, and that mapping feeds the shared IDs in #2.

No basis for a default yet: demo-vm-creator/README.md assumes one shared instance, 2-vcpu-quotas.ps1 says 48-64 vCPU per instance, deploy-localbox.ps1 says 32.

5. Providers: register once, fail loudly

60 participants × 25 providers is 1,500 Get-AzResourceProvider calls per subscription. Run it once per subscription, or reuse subscription-preparations/1-resource-providers.ps1. The Get-AzSubscription enumeration is dead weight from the copied script.

Error handling: no -ErrorAction Stop, so nonterminating errors skip the catch; caught errors downgrade to Write-Host; exit 1 only returns to deploy-lab.ps1; New-AzSubscriptionDeployment is unguarded. All four report incomplete prep as success.

Validation

What has been run end to end so far? Most useful:

1. Which deploymentType values deployed cleanly, and at what participant count.
2. A second run against the same lab, with no duplicate role assignments or errors.
3. Anything exercised against a real shared LocalBox.

Concurrency and re-run behaviour are the parts I cannot assess from the diff.

Nits: 99-MicroHack-Template/labautomation/main.bicep is empty, and resource-providers.ps1 prints an undeclared $SubscriptionId.

#2 and #4 gate a 100-person event. Happy to pair on either.