I wanted to write this post on when to decide on a new subscription or not.. but then it turned to security – which – as many of you know is close to me as well.. so while the beginning of this post is about “when to choose a new Azure subscription” the conclusion is: don’t have a cloud team that is owner of all your subscriptions

new/old Features

With the introduction of Management Groups and cross-subscription connectivity (vnet peerings, and even private endpoints) – the question that is often raised is: do I need a new subscription for this workload – or can I consolidate it into one?

The question of whether something should go into a single subscription is not easily answered. In the past it was based on networking connections, billing purposes, permissions, clarity of management and whatever someone would think would be appropriate.

Billing used to be the key identifier but – with tags, management groups and filters that can be applied to Azure Cost Management – that is no longer the case for quite some time.

Management might be another – but the advantage of Azure (compared to others) is the fact that there are so many ways to get to your workloads. Either directly via resource groups, the type of service deployed, via links of dependent services or just by searching for the object you want in the top search bar.

Location is rarely used for different subscriptions – let alone the resource group naming based on locations. Resources can be deployed anywhere even if the resource group is in another region. If you take the “vision” of cloud / DevOps where an application team is responsible for their workload – they should be able to deploy where they want (within the compliancy limits of the data/organization).

One thing does remain today however, a subscription has limits. If you (are going to) exceed those limits, you will need to have another subscription for your workload. But given a lot of these limits are “soft” limits and they can be raised, or these limits are so high – theoretically you will possibly never reach them under normal circumstances they do not pose a direct threat either.

Security

So, the limits are still a deciding factor, but let’s take a look at the other topics. The first thing that comes to mind and is essential in any business is security. And this is where the key to multiple subscriptions is. Each subscription has at least one “subscription owner”. The owner role gives the user(s) full access to all resources in the subscription, including the right to delegate access to others. This means that the subscription owner by default has access to anything in the subscription itself.

Giving it all away to 1 team

A lot of companies build a “cloud team”. They are responsible for all subscriptions and by default (or through Management Groups) are owner of all subscriptions. This is a habit that (I think) should stop immediately. It is giving a single group access to all resources and data and monitoring and delegation within your cloud workloads. Given your cloud workloads might also include domain controllers, essential business and PII data, encryption keys databases – would you trust a single account (or worse multiple accounts) with such access. In the case of a “cloud admin” account breach – that breach now extends to all subscriptions – and all mentioned above services and data. See – the problem with cloud is that its everything in one. Your datacenter, your OS layer, your application layer, your data and your security devices. While there is a strict audit and monitoring system available – by the time someone catches on to that – it’s too late.

Accounts with “subscription owner” permissions have great power. Not only the access to the services and data deployed – also the ability to wipe this all away.

I’ve had customers that (mistakenly in this case) deleted hundreds of VM’s and data through mismanagement and a wrong command.

Preventing a service meltdown

In my view – the RBAC problem will get bigger fast. As cloud usage increases year over year the core security problems we had when we “made everyone a domain admin – as it makes things work” are resurfacing today and are only slightly mitigated by MFA or biometric security on those admin accounts. My recommendation to any organization is to review their subscription owners, delegate permissions to essential groups and create silo’s in your workloads to shield them from others.

If you look at the “enterprise scale” landing zone provided by Microsoft as part of the cloud adoption framework – the management group and subscription organization does not include the segregation of duties. By placing a single group on the left top hand corner it looks like this group needs to be responsible for all subscriptions and containing resources. The change I’ve made above shows that one group might be responsible for creating these management groups and putting subscriptions in them, but then per management group another administrative group should be responsible for the workloads underneath it.

Subscription owner == domain admins and we don’t usually give out those rights easily…

To give a clear example; the identity subscription usually contains items like Active Directory domain controllers, RedHat IDM Kerberos Distribution Centers, Azure AD Connect or other identity management systems. These systems provide the core security components (authentication, accounts, groups). Only domain administrators (or equivalent groups) should have access to these subscriptions. If there is a “cloud management” group that has ownership of these subscriptions – they automatically have levelled up to the trust level of forest / domain admins (remember the security boundary in Active Directory is not a domain – it’s a forest). If you give someone “ownership” permissions – make sure those accounts are rarely used and heavily monitored – similar to how you should approach the domain admins group.

Governance and oversight?

But what about oversight? Someone needs to keep track of what’s happening in these subscriptions to avoid costs spiraling out of control! – Agreed. which is why in Azure there are so many other roles that can be used. Also roles that can be placed on the root tenant group to ensure they are present on all subscriptions – but with limited permissions. Such as Billing reader – to be able to read all related costs – but not change anything on the subscription. On a specific subscription for cost management – the same people can be billing contributors to ensure they can create and save dashboards. And there are so many other permissions that can be set.. just don’t make it owner.

Conclusion

Having a group of users with access to anything in your IT landscape will turn out to be a disaster. We need to make it hard on hackers to get into your systems and steal your data. So hard – they’d rather look somewhere else. By providing ownership of all subscriptions and hosted resources – you are essentially giving away “datacenter access, domain admins, sql sa, SAP admin, and all permissions” to a single group / user. Something you would not normally do .. so why do it in cloud?