Learning the Complexities of Role-Based Resource Management
We've selected our favorite tips and tricks created by Michael Crump as well as planned fresh technical content on Azure all April! Miss a day (or more)? Catch up with the series.
Don't have Azure? Grab a free subscription.
There are a lot of articles about how to write your first app, or how to get started with specific technology, and these are all fantastic resources. There is a hidden danger lurking that we don't often talk about which is the glue of how things work or talk to each other.
One of the often quoted maxims is "Don't log in as root," and so we don't, and yet we often do something that is pretty close.
Why not root? (or Administrator)
Root in the Unix and Linux worlds and Administrator in the Windows world refers to an elevated privilege account on the system. When we run an application with that elevated privilege, we are running all applications with those elevated privileges. Delete the whole file system? Sure, no problem! Run some malicious software accidentally? Sure! And I've helpfully given access to all data and hardware controls to the attacker as well.
In other words, not running something with elevated privileges allows you to limit the impact of accidents as well as limit the reach and impact of attacks.
Why not me?
You may or may not have elevated privilege, so maybe it's "ok" to run as yourself. You don't want to be the single point of failure for your organization with folks having to reach out to you to fix something that requires your credentials — or creating potential issues with sharing your credentials in code or with other people. One of the most common breaches is compromised credentials, so it's helpful to limit the impact of account takeovers.
Cloud Native Environments
Let's go back to the underlying problem that exists in many how-to articles. Many articles make things "easy" through the creation or use of existing root-level access keys in a cloud environment. When done from a personal account, that's dangerous, but the level of impact is limited. For organizations, this can have disastrous results and have a long-lasting impact on the trust of consumers.
There is a shared security responsibility in the cloud for your systems. Depending on the specific choice of services, the cloud provider handles some of the security. The more managed the service is by your cloud provider, the more security concerns are covered. For example, using a managed Database for MySQL on Azure, all the upgrades and security patches of MySQL are handled for you along with storage encryption, encrypted backups, and encrypted network connections. If you were to install MySQL on an instance though, you'd have to manage all the upgrades and patches and encryption yourself.
No matter whether you use infrastructure as a service, software as a service or serverless, you are 100% responsible for your data and the account and access management. In other words, when thinking about how to architect and create systems, think about all the different data you have, and the ways you have to access that data, and what permissions should be granted.
Azure Architecture
Let's talk about how Azure gives you the ability to implement controls to your data and services. When you log into Azure, your account is a unique global entity that gives you access to Azure service and any subscriptions you have access to with that identity. Subscriptions are how you pay for Azure usage. Each subscription is associated with a payment method. You can create subscriptions, and be granted access to subscriptions via your identity.
Everything in Azure can be considered a resource, for example, virtual machines, databases, and networks are all resources.
Resources may be grouped in resource groups allowing the management of the resources together. Resources are associated with a specific subscription, generally via resource groups.
Every feature of Azure has a resource provider which are the set of actions you can take on those resources. I've described a simplified model of this functionality to give you enough context to how things work.
Security principals are an object within Azure that represents a user, group, service principal, or managed identity.
A role is the collection of permissions to resource providers. Azure comes with a set of built-in roles, of which three apply to all resource types:
- Owner
- Contributor
- Reader
The "Owner" role is the wildcard permission, effectively granting "root" level privileges to all resources including the right to manage authorization to resources. The "Contributor" role is close to "Owner" in that it grants "root" level privileges to all resources, but it doesn't allow changing authorization to resources. The "Reader" role allows all view actions to resources except for secrets.
There are over 60 built-in roles that are more fine-tuned to specific resources. It's also possible to customize and build specific roles to meet your needs, but often one of the built-in roles provides precisely what is needed.
When granting access to resources, security principals have a role assigned to them at a particular scope. The scope can be a specific resource, resource group, or subscription. The goal is to limit assigned privileges to only what is needed.
A simplified way to think about how to bucket the grants you might want to make can be thought of as pictured, where observers are granted subscription/resource group scoped privileges with "Reader" roles for example.
Practical RBAC
There is a whole other article that I could write about the design process of thinking through design and implementing governance throughout your application or service. At the most basic level, think about the following:
- What data are you collecting or generating?
- What are the ways it is created, accessed or modified? (Including how you back it up!)
- What information is logged? Are you separating personally identifying information so that your logs aren't a source of data leakage?
Let's look at a single example: Think about how you would automatically install a SSL certificate for a custom domain name to your API gateway? The SSL certificate could be stored in Key Vault, and then accessed only by the security principal that had been granted access which simplifies the installation process and prevents the certificate from needing to be passed around.
Once you have a general idea of your data and the controls you need to put around it, identify the set of security principals you need. For applications, service principals or managed identities are the way to go. Managed identities are a fantastic addition to RBAC as they simplify the authentication process for resources with Azure managing the identity aspects (including rolling credentials regularly!). It isn't available for all resources yet.
Curious to see what roles already exist in your subscription? Check out how to look at roles in the Azure portal. It's possible to look up specific roles, or dig in at the subscription level to see all privileges granted. With managed identities, some roles are automatically created for you which is super helpful as they are automatically deleted with the resource group deletion.
Additional Resources
Check out these additional resources to level up your RBAC knowledge.
- Built-in Roles for Azure Resources
- Managed Identities
- Use the Azure portal to View and Assign Roles
- View and Assign Roles to Azure Resources with the Azure CLI
I look forward to sharing more about RBAC with specific Azure walkthroughs in my OATS series. How do you think about governance of your applications and services?
We'll be posting articles every day in April, so stay tuned or jump ahead and check out more tips and tricks now.
Top comments (0)