Make Storage optional for `deploymentScripts` resource

[jgbradley1]

Is your feature request related to a problem? Please describe. The Microsoft.Resources/deploymentScripts resource currently requires (at minimum) that a Microsoft.Storage/storageAccounts resource be deployed to hold the output from the job that is run. Based on what I have read, deploymentScripts does not fully support managed identity authentication to Storage accounts and requires a shared key or SAS token to work. This is problematic in situations where azure security policies no longer allow shared keys on storage accounts, causing any deployment code that uses the deploymentScripts resource to break.

Describe the solution you'd like Some use cases of deploymentScripts are pretty simple (sleeping to give managed identities time to propoagate through Entra ID) and users don't have a high priority need to see the output. It would be great to give users the option to execute a script without saving the output (and therefore eliminating the need for a Storage resource).

If the storage resource were considered optional for deploymentScripts, this would unblock MSFT teams in the short-term and enable simpler deployment scenarios while adhering to security requirements.

[jeskew]

@jgbradley1 Unfortunately, deployment scripts rely on storage accounts for more than just picking up script outputs. Dropping the script in a file share is the only way we can provide the script to the ACI instance in the service's current architecture, and the script has to write to a file for us to know whether it succeeded or failed.

[emilyredm]

@jgbradley1 We've discussed this internally with the Deployments team and identified a potential path forward. The ACI and Storage teams are actively working to address the underlying dependency challenges, and their solution is currently targeted for delivery in September. Since deployment scripts rely on these services, we anticipate being able to start implementation on our side once their updates are in place. We’re currently in the design phase and are staying in touch with those teams.

In the meantime, could you help us better understand the impact of this issue? Specifically, how critical is this for your scenarios, and how many deployments or teams are currently blocked or affected? This context will help us prioritize appropriately as we move forward.

[sebastienros]

I can give you some impact: no team at Microsoft can run scripts on the Microsoft tenant without explicit exemption. Keys are just forbidden. Indirect impact: no MS team can deploy SQL Server on MS tenants with best practices because assigning roles is done from a script. Mitigation: use the admin account such that we don't need scripts, but sometimes you just can't do that (and azure sql server has a unique admin).

[zxcvbnmwwr]

@jgbradley1 We've discussed this internally with the Deployments team and identified a potential path forward. The ACI and Storage teams are actively working to address the underlying dependency challenges, and their solution is currently targeted for delivery in September. Since deployment scripts rely on these services, we anticipate being able to start implementation on our side once their updates are in place. We’re currently in the design phase and are staying in touch with those teams.

In the meantime, could you help us better understand the impact of this issue? Specifically, how critical is this for your scenarios, and how many deployments or teams are currently blocked or affected? This context will help us prioritize appropriately as we move forward.

Not sure that it's possible to calculate how many teams are affected, because:

1. Some teams use workaround, and are fine with that(while it's allowed, as far as I know Deployment Scripts is a blocker for disabling SAS completely)
2. Some teams migrated off from deployments scripts on less convenient alternatives
3. Some teams don't use, despite they want to, because of limitation So, impact is much wider than the teams who clearly states that they can't use it due to this problem. Almost any deployment on prod requires running custom power shell script, even if it's just a few lines of code

[zxcvbnmwwr]

Additionally there are teams outside of microsoft which are affected by this issue: https://github.com/Azure/bicep-types-az/issues/2199

[zxcvbnmwwr]

One more scenario which is currently blocked and requires workaround is issuing certificates in KeyVault. Currently it's not covered by Bicep and requires using Azure CLI/PowerShell SDK and DeploymentScript bicep resource is the way to do that.

[igor-nesterov]

Hello @emilyredm Is there any updated ETA for this task?

[llxu1]

@SydneyhSmith Appreciate if you could provide any updated ETA.