Standard patterns for delegating prescriptive subscription access

Question

Looking for standard patterns for us as a central CCoE to provide a subscription to a customer that they control %99.9 of, but where we set some basic standards/foundations in the subscription they can’t change around:
• Network structure
• Logging
• Compliance tracking
• Etc

Between Azure Policies, Resource Locks, Blueprints, and Permissions there seem to be a number of ways to do this, but none that are simple and easy to implement and it feels like for a control to be reliable we’d have to implement a combinations of all of them for most use cases!

Our real issue here is that we would like to give users access to create custom roles – but we can’t see how to do that without letting the “jailbreak” out of other activities within their subscription.

https://learn.microsoft.com/en-us/azure/role-based-access-control/deny-assignments is very close to what we’re after, but obviously not us useful if they can only be created implicitly via Blueprints

Answer 1

This question is originally from me so I'll add some more information:

• We run a distributed operating model in our organisation where a central team runs the basic shared services and common elements per account, and then each customer is responsible for their own application's azure consumption within a subscription.
• The central team (i.e. my team) takes responsibility for keeping the "foundation" elements properly configured in each subscription
• The problem child right now is protecting the basic network setup (vnet, subnets, security groups on subnets) that implement our our network zone model
• This is hard/awkward to protect using Azure Policy as it's not just a checkbox/setting that needs to be in place, it's a whole specific set of infrastructure.
• There are a whole load of other items that need prescriptive setup as well (splunk integration, virtual machine management stuff, etc) but networks is the immediate issue.
• Currently customers are given owner access to their subscription, but if we have to change that we will.

We have considered using:

• Resource Locking. Where we lock the "foundation" resources, give the customers only a custom role that can't unlock/lock anything, and set a policy to stop them attaching any roles with unlock permissions. Seems possible but awkward as hell.
• Azure Blueprint Protection (not GA, but looks like it may be designed for our use case?)
• Putting all the 'foundation' elements into a separate resource group in sub, and only granting customers access to the other resource groups in the sub (awkward and/or needs automation)
• Tagging all foundation elements as foundation and using a attribute based access control to protect them (awkward as if we let customers assign roles we'd need a policy to stop them "jail breaking" out)
• Deny Assignments (no away to set directly)

I'm assuming we're not the only person with this sort of organisation model, so not the only ones with this sort of issue.

Answer 2

Hi @Harris (Tanuki) Lloyd-Levy
It sounds like your on the right track and asking the right questions. I think your approach to customer subscriptions aligns closely to our own guidance.

• Enterprise Scale Landing Zone describes how to handle most of the problems you have listed alternatively Blueprints with arm deployment and deny assignments should give you exactly what you need but understand the hesitation given the preview flag. If you cant use the reference implmentation for your landing zone. I strongly recommend following the documented design principles
  My thoughts are you will need multiple controls in order to achieve what you are trying to do:
• RBAC and custom roles, see the subscription owner example and how we remove permissions on specific resource providers
• resource locks
• azure policy. appreciate the feedback and understand its not the most intuitive experience to use policy to deploy resources. I would suggest starting with the Examples from Enterprise Landing Zone
• lastly Management groups for managing the above across multiple subs

Answer 3

Hi Tim - That's great info.

I'm reading that as we're pretty safe(ish) to use blueprint with locking right now, but in the future we may want to consider changing how we author them to use more template specs and biceps. Both of those seem like good ideas anyway.