Closed BrianVallelunga closed 1 year ago
I've confirmed this is the fix. When I change that line, it adds the following field to the ARM template:
"scope": "[resourceId('Microsoft.Storage/storageAccounts', 'mystorageaccount')]"
Deploying that assigns the correct permission to the storage account instead of globally. I'm happy to submit a pull request for this. It's the one line of code change plus a fix for the test.
I believe I found a bug in using the storage builder's grant_access function. I found this by trying to grant two different system identities access as a storage blob data contributor to two different storage accounts. I ended up with an error of
RoleAssignmentExists
.I traced the issue down to the following code (line 176 to be specific):
https://github.com/CompositionalIT/farmer/blob/287a0ff31d9f696215c61b90b7eaceedabe0c9ba/src/Farmer/Builders/Builders.Storage.fs#L171-L183
The problem is that the storage builder is granting the role at the resource group level, not the storage account level. So when the ARM template is generated, it leaves out the
scope
field from the JSON. I believe the correct code is:Scope = SpecificResource this.ResourceId
but have not tested it yet.