Tag Archives: RBAC

Understanding Tenants, Subscriptions, Regions and Geographies in Azure

If you are getting started working with Azure you might come across a few key terms that it’s important to have a good understanding of. In this post I’m going to cover what I think are four of the key ones.

Tenant

A Tenant, as it relates to Azure, refers to a single instance of Azure Active Directory, or, as it is often called “Azure AD”. Azure AD is a key piece of Microsoft’s cloud platform as it provides a single place to manage users, groups and the permissions they hold in relation to applications published in Azure AD.

Key Microsoft applications that Azure AD provides access to include Office 365, Dynamics 365 and Azure. Yes, you read that right, Azure is treated as an ‘application’. You can also use Azure AD to control access to many other third-party applications such as Salesforce and even the AWS admin console. As an application developer you can register your own applications in Azure AD for the purpose of allowing users access.

Azure AD Tenants are globally unique and are scoped using a domain that ends with ‘onmicrosoft.com’ (i.e. myazuread.onmicrosoft.com) and each has a ‘Tenant ID’ in the form of an UUID/GUID. Some customers choose to connect their internal Active Directory environment to Azure AD to allow single or same sign-on for their staff and will also use a custom domain instead of the default ‘onmicrosoft.com’.

When you access the Azure Portal, or leverage one of the command-line tools to manage Azure resources in a Subscription, you will always be authenticated at some point via the Azure AD Tenant associated with the Subscription you want to access. The actions you can take will depend on the Role you have been assigned in the target Subscription.

Finally, Azure AD Tenants can be associated with multiple Subscriptions (typically in larger organisations), but a Subscription can only ever be associated with a single Azure AD Tenant at any time.

Dev Tip: if you want to develop an application that uses Azure AD but don’t have permissions to register applications in your company’s Azure AD Tenant (or you want a ‘developer’ Azure AD Tenant) you can choose to create a new Azure AD Tenant in the Azure Portal. Make sure in your application that you can easily change Azure AD Tenant details to allow you to redeploy as required. Azure AD has a free tier that should be suitable for most development purposes.

IT Pro Tip: you can change the display name for your Tenant – something I strongly recommend, particularly as Azure AD B2B will mean others will see your Directory name if they are invited and may be confused if the display name is something unclear. Note that you are *not* able to change the default onmicrosoft.com domain.

Subscription

A Subscription in Azure is a logical container into which any number of resources (Virtual Machines, Web Apps, Storage Accounts, etc) can be deployed. It can also be used for coarse-grained access control to these resources, though the correct approach these days is to leverage Role Based Access Control (RBAC) or Management Groups. All incurred costs of the resources contained in the Subscription will also roll-up at this level (see a sample below).

Subscription costs view

As noted above, a Subscription is only ever associated with a single Azure AD Tenant at any time, though it is possible to grant users outside of this Tenant access. You can also choose to change the Azure AD Tenant for a Subscription. This feature is useful if you wish to transfer, say, a Pay-As-You-Go (PAYG) Subscription into an existing Enterprise Enrolment. Subscriptions have both a display name (which you can change) and a Subscription ID (UUID/GUID) which you can’t change.

Subscriptions are not tied to an Azure Region and as a result can contain resources from any number of Regions. This doesn’t mean that you will have access to all Regions, as some Geographies and Regions are restricted from use – we’ll talk more about this next.

Resources contained in a Subscription, but deployed to different Regions will still incur cross-Region costs (where applicable) for the resource.

People sometimes use the word ‘Tenant’ instead of ‘Subscription’ or vice-versa. Hopefully you can now see what the difference is between the two.

Regions and Geographies

Azure differs from the other major cloud providers in its approach to providing services close to the customer. As a result, and at time of writing (August 2018), Azure offers 42 operational Regions with 12 more announced or under development.

A Region is a grouping of data centres that together form a deployment location for workloads. Apart from geo-deployed services like Azure AD or Azure Traffic Manager you will always be asked what Region you wish to deploy a workload to.

Regions are named based on a general geography rather than after exactly where the data centres are. So, for example, in Australia we have four Regions – Australia East, Australia Southeast, Australia Central 1 and Australia Central 2.

A Geography, as it relates to Azure, can be used to describe a specific market – typically a country (Australia), though sometimes a geographic region (Asia, Europe). Normally within a Geography you will find two Regions which will be paired to provide customers with high availability options. Can anyone spot the one Region that doesn’t have its pair in the same Geography?

There are a few special Regions that aren’t open to everyone – US Government Regions, the entire German Geography and China. In Australia, in order to access Australia Central 1 and 2 you must undergo a white listing process to gain access.

When you replicate data or services between Regions you will pay an increased charge for either data transfer between Regions and / or duplicated hosting costs in the secondary Region. Some services such as Azure Storage and Azure SQL Database provide geo-redundant options where you pay an incremental cost to have your data replicated to the secondary Region. In other cases you will need to design your own replication approach based on your application and its hosting infrastructure.

Once you have deployed a service to a Region you are unable to move it – you have to re-provision it if you need the primary location to be somewhere else.

As a final note, while there is a Regional availability model (replication of services between Regions), Microsoft has also introduced the concept of Availability Zones. Availability Zones are still being rolled out globally, and are more than just a logical overlay over Regions. Interesting times!

So there we have it, a quick overview of some of the key terms you should be familiar with when getting started with Azure. As always, if anything’s unclear or you have any questions feel free to drop a comment below.

😎

Tagged , , ,

Azure Automation Runbooks with Azure AD Service Principals and Custom RBAC Roles

If you’ve ever worked in any form of systems administrator role then you will be familiar with process automation, even only for simple tasks like automating backups. You will also be familiar with the pain of configuring and managing identities for these automated processes (expired password or disabled/deleted account ever caused you any pain?!)

While the cloud offers us many new ways of working and solving traditional problems it also maintains many concepts we’d be familiar from environments of old. As you might have guessed, the idea of specifying user context for automated processes has not gone away (yet).

In this post I am going to look at how in Azure Automation Runbooks we can leverage a combination of an Azure Active Directory Service Principal and an Azure RBAC Custom Role to configure an non-user identity with constrained execution scope.

The benefits of this approach are two-fold:

  1. No password expiry to deal with, or accidental account disablement/deletion. I still need to manage keys (in place of passwords), but these are centrally managed and are subject to an expiry policy I define.
  2. Reduced blast radius. Creating a custom role that restricts actions available means the account can’t be used for more actions that intended.

My specific (simple) scenario is stopping all running v2 VMs in a Subscription.

Create the Custom Role

The Azure Resource Manager (ARM) platform provides a flexible RBAC model within which we can build our own Roles based on a combination of existing Actions. In-built Roles bundle these Actions into logical groups, but there are times we may want something a little different.

The in-built “Virtual Machine Contributor” Role isn’t suitable for my purposes because it provides too much scope by letting assigned users create and delete Virtual Machines. In my case, I want a Role that allows an assigned user to start, stop, restart and monitor existing Virtual Machines only.

To this end I defined a custom Role as shown below which allows any assigned user to perform the functions I need them to.

Let’s add this Role by executing the following PowerShell (you’ll need to be logged into your Subscription with a user who has enough rights to create custom role definitions). You’ll need to grab the above definition, change the scope and save it as a file named ‘vm-power-manager-customerole.json’ for this to work.

New-AzureRmRoleDefinition -InputFile vm-power-manager-customrole.json

which will return a result similar to the below.

Name             : Virtual Machine Power Manager
Id               : 6270aabc-0698-4380-a9a7-7df889e9e67b
IsCustom         : True
Description      : Can monitor, stop, start and restart v2 ARM virtual machines.
Actions          : {Microsoft.Storage/*/read, Microsoft.Network/*/read, Microsoft.Compute/*/read
                   Microsoft.Compute/virtualMachines/start/action...}
NotActions       : {}
AssignableScopes : {/subscriptions/c25b1c8e-1111-4421-9090-1a12d7012dd3}

that means the Role shows up in the Portal and can be assigned to users 🙂

VM Power Manager Role

Now we have that, let’s setup our Service Principal.

Setup Service Principal

Microsoft provides a good guide on creating a Service Principal on the Azure documentation site already so I’m not going to reproduce that all here.

When you get to “Assign application to role” hop back here and we’ll continue on without needing to dive into the Azure Portal.

For the purpose of the rest of this post, these are the parameters I used to create my Service Principal.

Name: Azure VM Start Stop SP
Sign-on URL / App URI: http://myvmautomation
Client ID*: c6f7c745-1234-5678-0000-8d14611e75f4
Tenant ID*: c7a48abc-1990-4fef-e941-a1cd55422e41

* Client ID is returned once you save your Application. Tenant ID comes from your Azure AD tenant ID (see Microsoft setup instructions referenced above).

Important: you will also have to generate and grab a key value that you will need to use as it is the password for the Service Principal. Don’t forget to grab it when it’s displayed!

Assign the Service Principal the necessary Azure Roles

# Assign our custom Role
New-AzureRmRoleAssignment -ServicePrincipalName http://myvmautomation `
                          -RoleDefinitionName 'Virtual Machine Power Manager' `
                          -Scope '/subscriptions/c25b1c8e-xxxx-1111-abcd-1a12d7012123'

# Assign the built-in 'Reader' Role
New-AzureRmRoleAssignment -ServicePrincipalName http://myvmautomation `
                          -RoleDefinitionName 'Reader' `
                          -Scope '/subscriptions/c25b1c8e-xxxx-1111-abcd-1a12d7012123'

We now have all the baseline mechanics out of the way – next it’s onto using this information in our Runbooks.

Asset Setup

Azure Automation has the concept of an Asset that can be one of six items: Schedules, PowerShell Modules, Certificates, Connections, Variables and Credentials.

These are shared between all Runbooks in an Automation Account and are extremely useful in helping you deliver generic re-usable Runbooks.

For this post we are going to create a new Credential using the following process.

Our Automation Account is called ‘Core-Services’ and is hosted in a Resource Group ‘rg-test-01’

$username = "c6f7c745-1234-5678-0000-8d14611e75f4"
$password = ConvertTo-SecureString -String "YOUR_SERVICE_PRINCIPAL_KEY" -AsPlainText -Force

$newCreds = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $username,$password

New-AzureRmAutomationCredential -Name "VMPowerServicePrincipal" `
                                -Description 'Service Principal used to control power state of VMs' `
                                -Value $newCreds `
                                -ResourceGroupName 'rg-test-01' `
                                -AutomationAccountName 'Core-Services'

This creates a Credential we can now use in any Runbook.

The sample PowerShell Runbook below shows how we do this using the Login-AzureRmAccount Cmdlet using the -ServicePrincipal switch.

I also specify a Tenant identifier (this is the Azure AD Tenant identifier from when you setup the Service Principal) and the Subscription identifier so we set context in one call.

The Tenant and Subcsription identifiers are held as Automation Account Variables which we read in at the start of execution (the pattern below allows you to override which Variables you pass in should you want to use different ones).

So there we have it – a way to perform VM power state management in an Azure Automation Runbook that uses a non-user account for authentication along with custom RBAC roles for authorisation.

Enjoy!

Tagged , , ,

Using Active Directory Security Groups to Grant Permissions to Azure Resources

Kloud Blog

The introduction of the Azure Resource Manager platform in Azure continues to expose new possibilities for managing your deployed resources.

One scenario that you may not be aware of is the ability to use scoped RBAC role assignments to grant limited rights to Azure AD-based users and groups.

We know Azure provides us with many built-in RBAC roles, but it may not be immediately obvious that you can control their assignment scope.

What do I mean by this?

Simply that each RBAC role (including custom ones you create) can be used at various levels within Azure starting at the Subscription level (i.e. applies to anything in the Subscription) down to a Resource (i.e. applies just to one particular resource such as a Storage Account). Role assignments are also cascading – if I assign “Owner” rights to a User or Group at the Subscription level then they have that role…

View original post 355 more words

Tagged ,

Azure Security Fundamentals: Moving Co-Admins to RBAC

I’ve been working on some engagements recently where we’ve been reviewing the current state of security capabilities in Azure, and with the recent General Availability of RBAC support in Azure I thought I’d write a quick overview on Kloud’s blog of how you can move from the traditional Administrator / Co-Adminstrator setup to leveraging RBAC.

Tagged , ,