Azure Governance - #2 - Organize your resources

I'm Dean cipolla and this is the Azure Academy so continuing today in our study of governance in the cloud let's jump right into the azure portal and in here we're going to go back to all services and go to the new Quick Start Center and to set up our Azure environment and again this is where we find all the highlights about governance we'll start here with managing access now as we said in our overview managing access has to do with these permissions these are back role based access controls and they break down by default into these layers and in these functions so you have a reader a contributor and an owner and we have those functions across every different kind of resource and technology in the cloud they can be then implemented at the subscription resource group or resource levels and within the mix of all of this you can also have custom roles that take pieces and portions of all of these things together and then you go and build a custom role for that grab people put them in that group that has this function and so now you can copy together the the roles of VM contributor with network reader and security reader and make that into a single role that then you give to your users and they can do jobs XY and Z now on top of that there's also this automated processes and that's because there are ways to assign resource permissions without people nonhuman service accounts or sometimes called service principle IDs are now called managed IDs in the cloud all these things together fall under automated processes which then you can use to execute code for you or do tasks or perform things under policy or as your automation those type of things so let's look at some of this in the portal I've gone to my subscriptions and here inside my subscriptions we have access control inside access control we have our type our name our role and our scope now the type here we have a few different kinds there's users that's individual people groups and then apps apps are these service principles or these managed identities that are in Asscher now under roles we have things like contributor and owner and reader and then there are custom roles like this one for the SA P cloud appliance library that I have and then we have the scope this is something that is applied at this resource level or it is an inherited scope okay and inherited can fall onto many different layers so if we go into my resource groups and we go to access control for that you can see here now I've got subscription inherited scopes okay and then we also have some items like my monitoring contributor and my storage account contributor which are a managed service identity which is an app that has been given the rights of monitoring contributor and sorting storage account contributor for this resource group only and it's applied at this resource group and we still have the role here of reader for inherited from the root and then we have some of the subscription so many different ways that you can apply these permissions as was discussed in our overview and now I want to walk you through briefly just setting a permission so to do that first thing we have to do is select a role so I will select the role of reader so now we'll type in an email address okay I have no idea if this is actually a valid place a valid email address I have no idea if this is a valid domain and asier doesn't care either because this is external to the cloud it just wants to know that this is a valid form of an email address and then you would select it here and it's going to be getting the role of reader and you hit save and it goes through to add the permissions and there we have the reader is now added of Denver is a great place at us places calm add it at this resource level now just as easily we can go and remove this okay and it is removed so just as easy to add as it is to remove permissions and the best thing to do from a management perspective is to use groups as much as possible for people and then you have apps which are these nonhuman service accounts that can be given specific roles and permissions at specific levels to do specific jobs so the example that I have here of monitoring contributor and storage account contributor using the same managed ID is so that I can use a policy to add diagnostic storage accounts to my network security groups if they do not exist okay and we'll get into some of that in our policy section so what else can we do from a governance perspective in our subscription or in our resource groups so as we talked about already there are policies and now we're looking at the policy blade inside asher and this is scoped specifically to our subscription now going back to our resource groups let's say that I pick this particular resource group and I look at policies here now we're scoped to just this resource groups view of policies and that would be different looking at another resource group okay see we've got different amounts of compliance and it just depends on how we're viewing the scope okay and we'll get into more of that in our policy discussion so some other ways to control your environment from a governance perspective is with Azure security center and whether or not you have that enabled whether or not you're enforcing policies and where you are enforcing them at the individual resource or the subscription level and then you also have under here you have resource providers which is a way to control what is allowed to be deployed into your environment for example there's plenty of things here that are Microsoft what about Citrix are you going to allow Citrix stuff to be deployed are you gonna allow live arena or or reven HQ databases so all different kinds of service providers that you can enable as well as many Microsoft services you do not have to enable them all if for example you decided you don't want your people using Azure stack don't register that provider or if you don't want using as your batch or the blueprint service or the bot service just turn those things off and that's how you can control what is permitted in your environment now additionally we talked about resource groups and subscriptions and that always brings up the concept of blocks what is a lock a lock is to be able to deny deletes or deny changes so let me go in here and I'll add a lock and this will be the change lock ok so now I've just added a read-only lock ok so now let me remove that so then we have delete locks like here I have some dev test lab stuff deployed in my subscription and you can see in the notes here it says that this is reserved resource that's locked by the AAA lab which is my resource group name ok so if I went to my resource groups and I went to the AAA lab and I look at the locks we can see those locks are in place here so resources cannot be deleted that fall under these particular child blocks so if I go to this storage account and I look at the lock we've got a delete lock here so what's gonna happen when I go to delete this storage account says sorry you can't delete it because it has a lock on it ok and you must remove the lock before you can delete this and only the owner of a resource can remove the lock so if there are locks like these that are placed at the subscription level then you cannot remove them you cannot delete things ok only the owner can do that ok so be careful where you put them definitely use locks especially delete locks inside your production environment to protect yourself so we've talked about some resource providers talked about locks a little bit about policies and let's get into some of the stuff at the resource group level now so we've talked about our hierarchy and we're gonna start talking about tagging now so tagging is again this key value pair and you can say things like Department is central IT or you can say application is called as you're learning or environment is the lab ok or another good one in the cost code or the cost Center okay so you can add these tags at the resource group level now very important to remember the resource group level does not propagate tags down to the individual resources so if we're at the resource group level and we just added these three tags and we go to this VM this VM happens to have these three tags as well but not because I gave them to the resource group level and I'll demonstrate that to you here so let me go back to here and I will delete the tag for the environment okay that's gone and we'll go back to that same VM and the environment tag is still here these all had to be applied individually to all of the resources and the application of a tag to a resource does not apply it to the resource group they are not connected to each other so let's say I wanted to put in another tag here and we'll say application type and we'll say web and we'll save that let me go back to the resource group level let me go back to tags not here and then consequently I will make another change here we'll call this one c3 and we'll go back to our VM and it does not inherit okay so tags do not propagate down to or up to resources or other resource groups they are 15 tags per resource is what you're allowed and they can be in any name value pair that you want to make up so I could have another tag here that called big thing and over here and call this mistaken identity and save now is that a helpful tag no of course it's not helpful it doesn't mean anything now in your environment perhaps that would mean something and if so feel free to use it if not use these kind of tags as a framework for knowing what your environment is knowing who's being charged for your environment what kind of thing is running in that environment maybe another one would be a decom date there you go so we know when this resource is planned to be decommissioned or shut down at 11 p.m. now why would something like that be helpful well back in our playbook under our tags there's a quote here about automation you can use regularly running scripts to use actions on tags like shutdown so I could run a script that said find every resource with this shutdown tag of 11 p.m. and turn them all off use some automation to help save you money and that's propagated through governance okay so we've discussed some of our stuff around our hierarchy some stuff around tags and now briefly I want to talk about naming standards and then we'll wrap it up for today when you go into your environment to have a planned naming convention tells you that things are related to each other and things are properly identified so that you know what something is by looking at it now in the portal we can see that these are availability sets and these are disks now if we were not in the portal if we were just looking at a billing piece of paper how would we know that the AAA - hypervisor is not a disk or a VM well we wouldn't necessarily know that but to have a name like a a - AV set - DC tells me this is the availability set for domain controllers same thing for disks hey - 2019 - data - one I know that this is a data disc this is the very first data disc in this particular VM or you can do your naming scheme with zero instead of one so all depends how you want to do it you can see pretty much everything here I have an a a prefix pretty much everything I wasn't completely consistent but the idea is consistency matters because now when I look at V net how do I know where that is so right now I have three virtual networks this one was named very distinctly this one is also named very distinctly this one is V net I don't know where it is I don't know what it is just to look at a piece of paper and say where's V net I don't know you look at this one and say where is this well this was for my contoso V net in East us for per diem novena one and it was called the shared - zero zero 1 V net so a very distinct name naming matters because everything needs a name in the cloud so we might as well be consistent so we don't end up with names like V net or Donald Duck to talk about things in the cloud and then nobody knows who owns it things aren't taxed so we don't know who it belongs to and we can't figure out who has to manage it because Charlie who used to do that left and now nobody knows ok so we want to head these things off before they become a problem so we've talked about some managing access and identity and we've also discussed some of our hierarchy as well as our naming standards and resource tags so in our next video we'll start talking about Azure policy and the azure security center hope you like this video please click on that subscribe button and that notification icon as well as hit that thumbs up and if you've got any suggestions for future videos give us a comment down below let us know how we can improve and happy learning

Channel: Azure Academy

Views: 6,388

Keywords: Governance, Azure, Microsoft, Academy, Azure Academy, Organize, Resources, Naming, Tags, RBAC, Providers, Locks, The Azure Academy, AzureAcademy, Microsoft Azure, AzureGovernance, Azure Governance, ARM, Template, ARM Templates, Automation, AzureRM, Azure Cloud Adoption Framework, Azure CAF

Id: eNTmIrw9qfE

Length: 14min 26sec (866 seconds)

Published: Mon Nov 26 2018