1. Overview of Azure Authentication and RBAC
Role based Access Control or RBAC. So just like Microsoft Azure ad is the preferred identity solution, using this type of role based Access Control is what Microsoft teaches. And this is what we’re talking about in this course. Now, the reason it’s called role based is because the idea is that you are going to create a role. So let’s say you have only four or five different types of users. If you could categorize them into roles, maybe you only have a handful of roles in your organization and then you assign tasks to those roles. So let’s say for this particular accounting app, you have the accountant and they have certain tasks. Maybe the developer needs access to this and so they get a different level of tasks and some other business person needs to get access and they have a different level. So these are examples of roles that you can create.
And so then you define the permissions for each of those roles. So if somebody is an accountant in your organization, what permissions do they have for this application? Maybe what you can define what permissions they have for some other application and those are a different set of permissions. You’re defining pretty granular permissions to each of the roles that you define in your organization. And then the final step is to identify which users are assigned to which roles. So instead of the old style, which is for every individual user, you assign them unique permissions for them. In this case, you’re doing a level of abstraction, which is that you have roles. Now, the advantage of that is that if you have a new user, that’s employee that’s joined your organization, you simply just need to pick which role they’re in and they’re already going to get a templated set of permissions and you don’t need to forget one or try to remember or copy it’s already there. You assign them as an accountant and they have all the authorizations as an accountant. Now, there are a set of roles that are predefined, there are dozens of them. But at top level rules, it’s either a reader level role, a contributor level role, or an owner level role. Now, reader level role in Azure is pretty much what it sounds like, which just means that the person can access the resource, but they can’t change the resource, they can’t modify it.
So if you have reader level permissions to a virtual machine, you can see that exists, you can connect to the virtual machine, but you can’t stop it, or start it, or delete it, or modify the settings, upgrade it, scale it up to a bigger one. Those things are denied because you’re only a reader level permission. The contributor level rule pretty much has full permissions to the resource. The difference between that and an owner level rule is that the owner can grant permissions to another person. So if you’re a contributor, you can stop and start a VM. You can delete it, create a new one. That’s sort of like the full permission. If you’re the owner, you can say to another user, here, I’m going to give you contributor level access, or give you owner level access. And that’s the ability to give permissions.
2. Resource Locks
Now, another type of authorization restriction that you can put is the ability to lock resources or resource groups. So let’s say you do have a virtual machine in your environment and you just don’t want anyone to make changes to it, so you can put a lock on it. You will then have to modify other people’s permission so they can’t delete the locks. Or maybe you do want them to allow them to delete locks and that’s an additional step that they have to take in order to make a change. So if you have a production resource, let’s say it’s your production website or your production database, you generally want to limit access to that to only people who are very specifically need access to it. But even those people should have some way of being warned before they make a change to that resource. So if you have your production database, even if only five people have access to it, it is possible to accidentally delete something.
You thought you were deleting the backup, but you ended up deleting the main one. You thought you were deleting a staging or development version, but you were logged into the wrong account. So putting locks onto resources protects them from accidents is one way of enforcing authorization on resources. So you go into the Azure Portal, as in the screen, and you can create a delete lock. In this case, it’s on a virtual machine that should at least tell you, oh, this machine has a lock on it, you can’t delete it. Like I said, you could then restrict people from delete the locks so they have access to modify the VM, but they don’t have access to delete it. And that delete permission has been reserved for only one individual, etc.
So you can arrange those permissions quite granularly as well. Let’s talk about tags. We saw this, this isn’t necessarily an authorization control, but it is metadata that’s associated with the resource. We saw this previously in this course when I was creating networks and virtual machines and other resources and was given a prompt within the wizard to associate tags. And I didn’t really stop at that time to explain it. So basically it gives you the ability to give metadata as you’re creating a resource, so you can modify that as well. Now, this is pretty good for something like billing. So when you have a big environment, you have dozens of resources or hundreds of resources, how are you going to determine which of your projects is going to get charged, which of your budgets is going to get charged for that resource? And you do that.
One way to do that is through tags. So you can say this virtual machine gets charged against the accounting budget and this virtual machine gets charged against the marketing budget, et cetera, et cetera. And so you can put tags for that. Now, it doesn’t force it to do that way, but it’s just information associated with the resource. You can also have the name of the person who’s in charge of the resource, the email address or some contacting. So if something was to happen, who do you call? Well, John Doe is associated with this, and we’re going to call him. So it’s data metadata that’s associated with resources.
3. Overview of Azure Policy
Next up, we’re going to talk about governance and policy. Now, there is a tool within Microsoft Azure called Azure Policy, which we’ll talk about in a second. The first thing we’ll talk about is the concept of governance. Now in general, the concept of governance is basically a body or a group of people who govern or set the rules or policies across a larger group of people. In a corporate context, you have the board of directors who are governing over the Clevel, executives who are governing over the vice presidents, and all the way down within the context of Microsoft Azure, you may have certain policies and rules that your company wants to enforce.
And so Microsoft Azure allows you to go in there and programmatically configure these rules. So when we were talking in the first section of this course about subscriptions and management groups, that is one form of governance. You’re able to organize your subscriptions in a nested manner, and you can set rules on various subscriptions or groups of subscriptions. And so this is what for purpose of the Azure policy tool. We can also look at this in the context of compliance. So let’s look at an example of some of the kinds of rules that you could enforce on your Azure subscription. You can enforce rules that restrict on the types of storage accounts that are subscription or a resource group or a user is able to create. You could restrict a user or a group to certain geographic locations, so you don’t want any resources to be created outside of Europe. And so you can put that restriction on your storage account so that it is not possible for any user who is authorized to use your storage account to create resources outside of Europe. You can do similarly against virtual machines. Some virtual machines are quite expensive. As you get up to the hundreds of CPUs and the super fast supercomputers, maybe you don’t want to allow those machines to be created on your account. You can restrict that.
We talked about resource tags in the last video, and maybe you want to enforce that certain resource tags must be used on every resource or set a default for a resource if a tag isn’t created, et cetera. So these are the types of built in policies that exist that you can activate against your account. You can also get creative and create your own policies. And this can be a little bit more complicated. So instead of being restricted to the fairly simplistic rules that come built in, you can then go and create more custom rules. I think what I’m going to do is switch over to the Azure Portal and we’re going to take a look at enforcing this type of policy as an example.
4. DEMO: Azure Policy
So we find ourselves back into the Azure Portal and I am going to do a search for policy that will bring up the Azure Policy Service. And we can see a bit of a dashboard here. I’m going to skip over that and go into the definitions. There are literally hundreds of definitions. If we scroll down here, we can see that there are, are lots of built in policies. So we’re going to have to do some searching to find the one that we want. Now the one that I want to talk about today is a policy that enforces that the resources are in the same geographic location as the resource group. So I’m going to search for resource location and I see that the search results bring back one policy. And I’ll click on it. It says audit resource location matches resource group location.
Now all policies are effectively JSON documents, even the built in ones. And we can actually read this code very carefully and determine what it’s trying to do. So it actually tells us it’s trying to make sure that all resources are in the same geographic location as the resource group that they’re in. As you may know, you don’t have to, it’s not necessarily required that resources are in the same location as their resource group, but maybe you want to set this policy in your company that you want them to enforce that. So if we go down to the policy rule, we can see, it says if field location not in resource group location, then it’s going to do an audit.
So this is just a reporting policy. So it’s not going to stop any resources from getting created. It’s not going to affect the users directly, but it is going to show up on a report and you can then see how people are complying. So if you have this as a company policy, you tell all the people who are allowed to create resources that they must create resources in the same region as the resource group, then this is going to tell you who’s not listening to that. So I’m going to accept that this policy is something I want to enforce. And so I’m going to say assign. Now I do need to choose the scope of what this policy is going to affect. We can choose the management group level.
So let’s say we have one management group and underneath that we have three subscriptions. If I assign it to the management group, then I could effectively force all the subscriptions under the management group to follow this policy. So even people who have authorization to control single subscriptions wouldn’t be able to override that because the management group has precedents essentially. But I can actually say, no, I only want this to affect a single subscription. And so this single policy could be assigned to the entire subscription. But wait, there’s more. We can go down to the, a specific resource group level so let’s say that I want to enforce on my AZ 900 course resource group this policy, but not affect any other resource groups. So I can assign this policy to either the measurement group level, the subscription level, or to an individual resource group. You know, I can give a particular description. It’s going to keep the assignment name by default. I could override it. The other thing I can do is I can exclude specific resources. So let’s say we don’t want, for instance, within this resource group, we have a database and we have a storage account. Let’s say we’re like, you know what the database is, okay? We don’t mind that the database is not in this region.
So we could exclude a specific resource in a resource group or in a subscription, again, enabled or disabled, and it’s going to be associated with myself. So if I click review and create and say create, it’s going to take around 30 minutes for the policy to kick in and then it’ll start showing up on my reports. But you can see here that you can basically set any kind of restriction or policy on your resources in an account. And this is sort of superseding your RBAC rules. And maybe it’s just a policy that you send out by email and say, hey, people, don’t do this. Well, you can now go in and enforce whatever it is that you can think of. We were talking about tags before.
There are dozens of built in policies around tags. Add a tag to resources, require a tag on resources, require a tag on resource groups. Even a subscription can be tagged. Or we can say inherit a tag from the subscription. So if we go into inherit a tag from the resource group, we can see that it takes in the tag as a parameter and then it checks to see the tag is not blank. And if it is blank, it will modify the tag and basically assign the resource group’s tags to the resource. So this is actually pretty cool too. So you can basically sign tags at the resource group level and all of the resources in that group inherit the tags. So you can see this is the perfect example of the kind of thing that you can choose to implement that will actually save you time, make your life easier.
For all the reasons tags are good to use, you can actually enforce their use or do a cool kind of default like this. So Azure policy is basically where you set up these defaults and you set up these rules. They can either be enforced, you can block resources from being created, or you can just audit them and it will show up on a report to see how people are in compliance with your rules. You can see here that some of the rules that I create, terrible compliance, 82% are non compliant. So I create rules and I don’t really follow my own rules. But you can have this kind of report for your own subscription, for your own company.
5. Azure Blueprints
Another governance related feature within Azure is called Blueprints. Now, Blueprints are basically a set of templates that you can create that contain users and roles and policies. You can basically create a bundle of these things and every time you create a new subscription you can create it from a Blueprint. So instead of your subscriptions being started as empty, they’ll basically start with a template full of your existing policies and roles in some of your security settings. So I’m going to switch back over to the portal and then we can see what Blueprints look like in action. So we’re back in the portal. I can search Blueprint in the search but actually there is a convenient link to it from within the policy section. So I’m going to click into blueprints.
This Getting Started page just sort of gives me some clues as to how to start. We’re going to switch over to the definitions. Now, I already have one Blueprint created, but I’m going to create a second one here. So like I just said, the concept here is that Blueprints are a combined set of policies and roles that you can then use to create brand new subscription from. You can start from blank and basically then start to create your own roles and policies. Or there’s actually a predefined list of some recommended ones and you can see that they’re typically country specific. So we’ve got Australian government, blueprint, Canada, federal blueprint. FedRAMP is an American one HIPAA for health care, IRS has one, NIST is another, us National Security Administration UK. So if you want to align yourself to a HIPAA compliant set of policies, we can certainly choose the existing Blueprint. Let’s switch over to well, first we have to give the Blueprint a name. So I’m going to call this second Blueprint.
Now, this policy is a JSON file. It’s going to have to live somewhere. So it’s going to have to live in either a management group or a subscription. So I’m going to set it to the management group level in this particular case. Now I can see what is inside this. So there are high trust HIPAA set of policies and there’s a bunch of values. It looks like there’s about 92 values or something that has to be filled in. But application names have to have a particular prefix, storage accounts have to be prefixed. Some of this has to do with the naming of your resources. Users excluded from administrator groups. You can sort of see the policies that are bundled together here. Virtual networks where VMs should be connected, distriction settings. I haven’t used this in production setting, but you can see that there’s just a lot of policies.
So if this is the kind of thing that you think, oh, I want to use the preexisting HIPAA settings, you can certainly use theirs. Now of course you could also then just create a blank 1 second Blueprint can set it to the management group level at this time. You’re going to have to go and find the policies and the rules. You can see what gets put into there. So do we have default resource groups that must exist in every subscription Arm templates? So maybe you’ve got an existing set of Arm templates that show you how to create VMs and storage accounts and other things roles of course the security settings within your active Directory and the policies we’re just talking about.
So you can basically say which are the policies that must be set on every subscription underneath this management group and you just go down the list and you start doing that. So hopefully you can see the Blueprints are basically templates and they contain these types of resources and then you basically can create subscriptions off of the Blueprint which forces the subscription to already pre populate with the things that your company wants them to have.
6. Cloud Adoption Framework (CAF)
So we’re still talking about policy and governance. In this video, we’re going to talk about the Cloud Adoption Framework for Azure. Now, Microsoft has published a set of documents and tools to help you on your journey from onpremises applications and selfhosted into the Cloud. We’re going to want to check out if this is something that you are in the process of evaluating, you’re going to want to check out the published documentation around that. So Cloud Adoption Framework, it’s documentation, guidance and tools in there contains Microsoft’s learnings their best practices for companies and organizations who are looking to make this move.
Now this is going to be a fairly generic overview because every company is different. If you’re a government organization, or you’re 100 person firm, or you’re a 50 person firm, you’re all going to have different needs. But Microsoft has tried to put everything together in terms of why you want to move to the cloud and how you’re going to do it, and some best practices along the way. Pulled from the cloud adoption framework is this path.
And hopefully it makes pretty much sense to you. You start with a strategy, understanding why you want to move to the cloud, what you’re hoping to accomplish, set some expectations in terms of your objectives, is there some business sense for doing so, and then you start to do the planning around that. So once that has been approved, you have a strategy, you create a plan, then you get the sign off on the plan, everyone is ready to go, and then you start this migration. And so I again recommend going into the documentation. You can see the Cloud Adoption Framework having some basic questions and then guide specific to different scenarios.
So if you are migrating, you’re in one camp. If you’re developing brand new applications, you’re in a different camp. If there’s some challenges or obstacles, there’s some guidance around that. So this is on the exam and worth looking at. The Cloud adoption framework. If you’re process of migrating, thinking about migrating, doing the planning and strategy, this is where you go.
