[Modules] Microsoft.Storage/StorageAccounts and Microsoft.KeyVault/vaults policy exemption #2997
Conversation
|
@shawntmeyer This is a new feature that we are introducing like how we do RBAC on resource level. may I suggest we put this one on hold to bring in this topic into one of internal discussions. I will tag the issue #2996. as well. |
There was a problem hiding this comment.
Create stuff in any case. The only caviats I'm seeing are
- Increased file size (paying into the 4 MB limit)
- In theory there could be one excemption per resource type, I guess
Also I hope normal contributors won't have the permissions to just deploy excemptions 😄
AlexanderSehr
added
enhancement
eriqua
changed the title
|
Marked as draft as per offline discussion |
shawntmeyer
changed the title
modules/Microsoft.Storage/storageAccounts/.bicep/nested_policyExemptions.bicep
Outdated
Show resolved
Hide resolved
| @@ -338,6 +349,21 @@ module storageAccount_roleAssignments '.bicep/nested_roleAssignments.bicep' = [f | |||
| } | |||
| }] | |||
|
|
|||
| resource storageAccount_policyExemptions 'Microsoft.Authorization/policyExemptions@2022-07-01-preview' = [for policyExemption in policyExemptions: if (!empty(policyExemptions)) { | |||
There was a problem hiding this comment.
Wouldn't the storage account deployment be already blocked before we even make it to the excemption?
There was a problem hiding this comment.
it is not, the storage account is deployed. The common tests for both storage accounts and key vaults deploy a policy assignment that denies the creation of a resource that doesn't meet the policy. I verified that the test is a true test in that the resource doesn't meet the policy, but the exception works and the deployment succeeds.
There was a problem hiding this comment.
Is the policy a deny or an audit policy?
There was a problem hiding this comment.
@eriqua, it is a Deny policy (https://portal.azure.com/#blade/Microsoft_Azure_Policy/PolicyDetailBlade/definitionId/%2Fproviders%2FMicrosoft.Authorization%2FpolicyDefinitions%2Fc9d007d0-c057-4772-b18c-01e546713bcd) and in the test deployed with the Deny effect. Same for Key Vault.
There was a problem hiding this comment.
Interesting. I'm inclined to see this as an unexpected behaviour of the policy. Probably due to timing? I'm very confused as I'd expect the deny policy to deny the creation of an uncompliant resource, by definition 🤔
There was a problem hiding this comment.
This is exactly why I needed the PR. We can not create Resource Level exemptions without the resource ID and we can't create the resource with a deny policy in place without the exemption. The only way to do this is through ARM as a single deployment. ARM sorts it out and allows the resource to be created due to the exemption. Without this we would have to temporarily place an exemption at the RG level or disable the policy.
|
Marking as draft until we found the best way to integrate this |
Description
This update adds the deployment of policy exemptions at the Storage Account and Key Vault resource levels which is a useful deployment orchestration when we must deploy storage accounts or Key Vaults with public access allowed and we have policy deployed at a higher scope that blocks that resource creation. Addresses Issue #2996.
Pipeline references
Type of Change
Please delete options that are not relevant.
Checklist