How to lock down a single confidential Resource Group in Azure

This is a short one, but something I couldn’t figure out without testing it first.

Let’s assume a scenario where a company has a single Azure subscription. They also then have a single Azure tenant (meaning, a single Azure AD). Within this Azure subscription, they’ve built services for years and now have more than 100 resource groups.

They’ve now built another service that requires 10 resource groups – for testing, production, QA, and all sorts of things. As this service is very different and will store confidential data, they have to lock down access to the service within the Azure subscription. Not even admins can peek at the databases or any of the services within the resource groups – unless granted access.

How do we configure this?

Let’s start by taking a look at one of those resource groups we need to lockdown. I have one resource group named azuresentinel, and it’s hosting my Azure Sentinel and relevant services for that. Checking under Access control (IAM) on Azure Portal, we can see the default permissions:

A few inherited permissions from the Azure Subscription level. One from a Management Group and a few settings at the root level.

I want to remove the legacy Cloudyn account, which is no longer a useful service for me (the third from the bottom in the list). I select the Reader-level permissions and click on Remove in the top toolbar. Only to get this message:

Because the permission is inherited (from the Azure subscription, we only have one), the inheritance cannot be broken at a lower level, like a Resource Group.

Let’s see on the Subscription level if I can tweak this permission higher up in the chain. By selecting the same account and access, I can remove it – at the subscription level:

But this takes away ALL access for said account, everywhere! I only want to remove access for one Resource Group.

Going back to the Resource Group > IAM view, I see there is another tab called Deny assignments. Perhaps I can create a classic Deny setting within a Resource Group to remove access for specific accounts.

The description implies this would work. But it also cleverly states “at this time“, as if some sort of an update is impending for this feature. Thus, the only option is to create a new Azure Blueprint, and assign that to the Resource Group.

Seems awfully clumsy – I just want to remove permissions for 10 users, but not for 2 other users within one Resource Group. And creating a Blueprint just for this feels overkill.

Taking a look at creating a Blueprint, it clearly states that I need to select a lock assignment. The guidance, which is found here, then lists the lock levels: don’t lock, read only (for RG), read only (non-RG) and do not delete. None of these remove permissions – they just allocate locks, via assignments, that users don’t accidentally remove something important.

Back to the drawing board

So, it seems impossible to remove permissions for users who have inherited access from the Subscription level. Removing their permissions at the Subscription level would mean they lose all access – and re-adding that might be tricky and time-consuming, especially for admins.

We can, of course, audit access to our confidential and protected RGs. But even then, it would be time-consuming to monitor whether or not someone lists all the resources in an RG, either by accident or on purpose.

Using Azure Blueprints seems to be the preferred Microsoft approach, but it isn’t tackling the issue – it’s simply adding another method for protecting for accidental deletions mostly. It seems impossible to lock down a single Resource Group unless locking down a whole Subscription by removing all accessible for everyone (and granting those permissions later at resource levels).

The solution? Provision a new Azure Subscription, and move your confidential Resource Groups there. Lockdown access at the Subscription level.

I found a few feedback items (here, here) on this very same challenge from recent years. But no other fix than to deploy Blueprints for locks.