Petri Newsletter Sign-up
Office 365 Insider

Here at Petri.com, we get IT — and so can you. Subscribe today to stay informed and knowledgeable regarding the latest on IT.

    See All Petri Newsletters

    Getting Started with Role-based Access Control in Azure

    Posted on by Michael Teske in Cloud Computing, and Security

    To suggest security is “on the radar” for anyone moving to the cloud would be a dramatic understatement. But here we are. One thing I have discovered when talking with peers is there are a lot of gaps in fundamental security concepts out there. It’s critical to start your cloud journey with security in mind and being mindful of tools Azure provides out of the box. Yes, there are some extremely useful new services that can be leveraged, however, having the fundamental understanding of creating a secure cloud experience from the outset is just as important. I agree, learning fundamentals may not be as sexy as kicking the tires with Azure Sentinal, but they are extremely critical in improving your cloud security posture. In this article, we will take a look at how we can take a step in creating a secure platform by exploring role-based access control (RBAC).

    What is Role-Based Access Control?

    There are several approaches to security. Providing access on the need to know and more importantly, least privilege security principles are critical for any organization both on-premises or in the cloud. This is where role-based access control comes in. RBAC allows you to assign permissions to users, groups, and applications at different scopes. In Azure, the scopes at which these rights are assigned are subscription, resource group or a single resource.

    For example, your Global Admin can assign the role of Virtual Machine Contributor to Janis within the subscription. This grants Janis the right to create, delete, or modify any virtual machine within the subscription. Maybe Janis really only needs to view virtual machines within a particular resource group, but yet, she has the ability to spin up any type of VM or delete existing with the Virtual Machine Contributor role.

    Often times we assign more rights than necessary because it’s easier and things just work. This is not new. However, in the cloud, we must be mindful of least privilege more than ever because bad things can happen. We really need to assess what Janis needs. If all she needs is to see the assets in the resource group, we simply need to grant Janis the role of Reader, thus narrowing the scope of Janis’s rights which is a better practice falling under the least privilege security principal.

    What are Security Principals

    In short, security principals are who or whatever is being assigned the role or right. Take file permissions for instance. If I assign Todd the read permission to a document, Todd is the security principal. There are categories of security principals in Azure, very similar to what you have on-premises:

    • User: any user who has a profile in Azure Active Directory
    • Group: multiple users are assigned to a group, and roles can be assigned to groups, thereby impacting the users of that group.
    • Service principal: a security ID for apps and services
    • Managed Identity: used when developing cloud applications to help with credential management.

    Azure Built-in Roles

    There are quite a few built-in roles in Azure. The four most commonly used roles are:

    • Owner-has full access including the right to delegate (grant other security principals) access.
    • Contributor-has same access as owner other than delegation of access.
    • Reader-Can view existing Azure resources.
    • User Access Administrator-manage user access.

    Assigning a Role to a User

    Let’s go ahead and assign Janis the role of Reader for our resource group named demo-rg. As of right now, Janis cannot see any virtual machines within that resource group while she is logged into the portal. (see below)

    1. Sign into your Azure portal with an account with user rights privileges.
    2. Locate your resource group, in this case, it’s demo-rg.
    3. Click Access Control (IAM).
    4. Click Add and choose Add role assignment.
    5. Type Reader in the Role assignment blade.
    6. Select your user(s) and save.

    Due to this being the cloud, role assignment isn’t instantaneous. I’ve found logging in and logging out seemed to expedite the process. Or just go grab a cup of coffee and the role should be assigned when you return. Now, if we select virtual machines (or click on the demo-rg), Janis can now see all assets in that resource group, including the virtual machines (see below. She only has the reader role which would adhere to least privilege security philosophy if this is all she needs.

     

    Final Thoughts

    Access management for Azure resources should be high on the priority list. Leveraging out-of-the-box tools such as role-based access control can make that job much easier, especially when implementing from the ground up with a thoughtful plan in place. RBAC allows us to manage the who, what, and when in the cloud:

    • Who should have access?
    • What can they access?
    • When can they access it (Just in Time)?

    Take time to explore how you can create a stronger security profile by checking out the Azure Security docs site. There are several Security Best Practices white papers that go into great depth in securing the platform. You can also find some great RBAC tutorials including how to create and apply using PowerShell and Cloud shell located here.

    BECOME A PETRI MEMBER:

    Don't have a login but want to join the conversation? Sign up for a Petri Account

    Register