Creating a custom Azure Policy definition

Question

Hi everyone,

I'm working on creating a custom Azure Policy.

I need to allow a small group of users, let’s call them user A, B and C, to access a few specific Blob containers (in a storage account). 

I don't want to allow the users directly. I want to create a user group on Entra ID, let’s call it group S, and add those users to group S. I will then create role assignments not for the individual users but only for group S, so that I can have the role assignments centralized. 

I need to make sure that:

1. Nobody can assign any role to users A, B and C. (Other users are not affected)
2. Nobody can assign roles to group S that are outside of the scope. If I say that groups S should be able to access 2 specific Blob containers in a storage account, then I need it to be impossible for anyone to give group S permissions to access any other resource.
3. Nobody should be able to give a different kind of access to group S for those Blob containers. For example, if I say that groups S should have the Storage Blob Data Contributor role for those Blob containers, I want to forbid anyone to assign group S the Storage Blob Data Owner role for those Blob container.

I’m happy to use a different tool other than the Azure Policies if those aren’t able to achieve this outcome. If only a partial result is possible through the policies let’s talk about it.

At the moment I'm working on splitting the problem in two:

• Create a policy to forbid any role assignment to a few specific users (those referred to as user A, B and C in the example above)
• Create a second policy to forbid any role assignment for the users' group (referred to as group S above) outside of the scope.

A draft for the first part would be:

{
  "mode": "All",
  "parameters": {
    "usersObjectIDs": {
      "type": "Array",
      "metadata": {
          "description": "The list of users that should never have any role assigned.",
          "displayName": "Users for which we want to forbid role assignments."
      },
      "defaultValue": ["<user-a-object-id>"]
    }
  },
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Authorization/roleAssignments"
        },
        {
          "anyOf": [
            {
              "field": "Microsoft.Authorization/roleAssignments/principalId",
              "in": "[parameters('usersObjectIDs')]"
            }
          ]
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

I'm not 100% sure it'll work as I want it to yet. I'll test tomorrow. In the meantime, any help for either the first or second part is welcome. Thank you for your time. Cheers, Marco

Answer 1

Hey @Marco

To restrict users of the group on specific blob containers, you can try the following policy

{
  "if": {
    "field": "principalType",
    "equals": "Group",
    "field": "principalName",
    "equals": "GroupS",
    "field": "actions",
    "notEquals": ["Microsoft.Authorization/roleAssignments/write", "Microsoft.Authorization/roleAssignments/delete"],
    "equals": "Microsoft.Authorization/roleAssignments"
  },
  "then": {
    "effect": "deny"
  }
}

Enforcing assignments for only group S within specific blob containers could look like the following but I would suggest using some sort of pattern logic in place of {cotaniner1} instead of listing each individual container.

{
  "if": {
    "field": "principalType",
    "equals": "Group",
    "field": "principalName",
    "equals": "GroupS",
    "field": "scope",
    "notEquals": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Storage/storageAccounts/{storageAccount}/blobservices/default/containers/{container1}",
    "field": "scope",
    "notEquals": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Storage/storageAccounts/{storageAccount}/blobservices/default/containers/{container2}",
    "equals": "Microsoft.Authorization/roleAssignments"
  },
  "then": {
    "effect": "deny"
  }
}

These haven't been tested and may need some massaging to fit your use case but should get you pointed in the right direction.