If you are doing Azure, you probably also want the same, or better, control with your resources as you have on premise. Azure Resource Manager has some great capabilities to do this, which I will walk through in this post. In the coming week I will go into more details on how to use each of these features.
Role based access control
If you have been using Azure since before Azure Resource Manager came along, you will know that access to resources was a Yes/No decision. There was no way to limit the access users had, either they were administrators, or they didn’t have access. That is of course not suitable for most companies, as we should be able to do more granular control.
Enter Azure Resource Manager, and Role Based Access Control (RBAC) came along. With RBAC we can do fine grained access control and only give users access to the resources they should have access to, not more, not less.
Access is given by assigning roles to users. There is a lot of built in roles which lets you give access on different levels;
- Reader
- Contributor
- Owner.
Reader will only allow users to view resources, not change anything. Contributors can do write and delete, and Owners has full control over the resources. These roles can also be assigned on a per resource type level, so you can have Compute (Virtual Machines) Contributors, that won’t have access to anything else than Compute. You will also have reporting available to see if any access changes was made, and who made the change.
At the time of writing, custom roles are not available, but this feature is right around the corner so stay tuned.
Policies
Policies gives us the ability to limits the resources that can be created within a Resource Group. We can currently create policies for the following scenarios:
- Tags
- Locations
- Services
- Naming
I would expect this list to grow over time though. I have requested the ability to make policies of which sizes of VM’s (and other resources) can be created, which I would find very useful. I’ve worked with several clients who has asked for that specifically, and it makes good sense in terms of economics, so companies can control the usage.
The above policies are a good start though. By requiring specific tags on your resources, you can easier who the owner is, which department it belongs to, or if it’s dev/test/production environments, or whatever tagging policy you have.
The location policy limits the locations that can be used. You can do this either by blacklisting specific locations, or whitelisting the ones you want to use.
Creating policies about resources/services will limit which resources can be created in the resource group to which it’s applied. Some companies might want to use only storage, network and compute and can then deny all other resources from being created.
The naming policy is also very interesting in my opinion. I’ve seen so many companies with naming conventions. A lot of them has trouble enforcing these naming policies, either because people don’t agree with it, or due to mistakes when creating them. This policy will simply restrict creating policies that do not meet the requirements.
It’s important to note that these policies are applied at Resource Group level, so if your users has access to create Resource Groups, they can work around these policies!
Tags
Tags are also a key feature I think. It’s a very simple, yet so effective feature, and it’s very easy configure too. By tagging your resources, you can easily get a better understanding of the resource you’re looking at. There is no restrictions as to what tags can be used, so you are free to decide your own policy about this. Tags consists of key/value pairs, where the key is what you want to identify the resource by, and the value is the value of your identifier (key). My recommendations about what tags to use is:
- Environment – dev/test/prod
- Department – finance/marketing/IT – Where should the cost of the resource be billed, for example
- Responsible – Bob/John/Jane – Use it to identify the admin/user responsible for the resource
- Role – Web/Database/Application
The above tags could help you identify the resources easily, but there is no “one size fits all”, so consider what fits your needs. Tags are listed on your Azure bill, so you will also be able to see what a specific resource – or group of resources – costs if you use tags to identify them.
Locks
Locks will allow you to lock down your resources and prevent accidental deletion or changes. This is very useful in production environments where you do not want changes, or if you have periods of time where changes are not allowed. The Resource Lock feature has 2 modes:
- CanNotDelete
- ReadOnly
CanNotDelete will prevent anyone from deleting the resource, unless they remove the lock. People will still be able to modify the resource, and for example change the size of a VM or stuff like that.
ReadOnly mode will prevent both deleting and modifying the resources
Locks are not dependent on user roles, but you can manage who can create/remove locks, so everyone does not have this permission. The role a user is member of, should have access to Microsoft.Authorization/* or Microsoft.Authorization/locks/* actions. Only the Owner and User Access Administrator roles has access to those, but you could also create your own roles to reflect your organization.
Resource Locks are inherited from parent scopes, so if you apply a ReadOnly policy at the resource group level, al resources within the resource group, will be ReadOnly. If multiple policies apply to the same resource, the most restrictive one will be effective. Taking the above example, and adding a CanNotDelete policy to a resource within the resource group, the effective policy will be ReadOnly.
Find all parts of this series here:
-
Taking control of your Azure resources with RBAC, Policies, Tags and Locks (This post)
- Taking control of your Azure resources – Part 3 – Tags
- Taking control of your Azure resources – Part 4 – RBAC
- Taking control of your Azure resources – Part 5 – Locks
Cloudpuzzles 
2 comments