🤖 [AI] Filed from findings raised in discussion #2283.
⚠️ Problem
The hub's storage accounts (hub-app.bicep, infrastructure.bicep) hardcode allowSharedKeyAccess: true with no parameter to change it. Organizations enforcing the built-in Azure Policy "Storage accounts should prevent shared key access" (common in CAF/landing-zone environments) can't deploy FinOps hubs without a policy exemption.
Nothing in the hub's pipeline actually depends on the storage account key — Data Factory already authenticates via managed identity + Storage Blob Data Contributor RBAC.
🛠️ Solution
Add an opt-in allowSharedKeyAccess parameter (bool), threaded through main.bicep → hub.bicep → the storage account resources in hub-app.bicep and infrastructure.bicep, following the same pattern as the recent opt-in Key Vault RBAC parameter (#2249). Default to true to preserve current behavior for existing deployments.
Note: allowSharedKeyAccess is a live-mutable property (confirmed via Microsoft Learn — no resource recreation needed, and it can be flipped at any time via ARM/CLI/PowerShell/portal). That's exactly why the default shouldn't just be flipped to false outright: doing so would silently change live security behavior for every existing hub on its next redeploy, potentially cutting off any client outside our pipeline that relies on the key. An opt-in parameter avoids that.
ℹ️ Additional context
Same problem class and precedent as #1067 / PR #2249 (Key Vault RBAC opt-in).
Related: #2283 (discussion)
🤖 [AI] Filed from findings raised in discussion #2283.
The hub's storage accounts (
hub-app.bicep,infrastructure.bicep) hardcodeallowSharedKeyAccess: truewith no parameter to change it. Organizations enforcing the built-in Azure Policy "Storage accounts should prevent shared key access" (common in CAF/landing-zone environments) can't deploy FinOps hubs without a policy exemption.Nothing in the hub's pipeline actually depends on the storage account key — Data Factory already authenticates via managed identity + Storage Blob Data Contributor RBAC.
🛠️ Solution
Add an opt-in
allowSharedKeyAccessparameter (bool), threaded throughmain.bicep→hub.bicep→ the storage account resources inhub-app.bicepandinfrastructure.bicep, following the same pattern as the recent opt-in Key Vault RBAC parameter (#2249). Default totrueto preserve current behavior for existing deployments.Note:
allowSharedKeyAccessis a live-mutable property (confirmed via Microsoft Learn — no resource recreation needed, and it can be flipped at any time via ARM/CLI/PowerShell/portal). That's exactly why the default shouldn't just be flipped tofalseoutright: doing so would silently change live security behavior for every existing hub on its next redeploy, potentially cutting off any client outside our pipeline that relies on the key. An opt-in parameter avoids that.ℹ️ Additional context
Same problem class and precedent as #1067 / PR #2249 (Key Vault RBAC opt-in).
Related: #2283 (discussion)