Learn IAM (Identity and Access Management) in AWS

hey there everyone hes here back again with another video and in this video we will be learning and moreover discussing about the I am of AWS too many acronyms identity and access management for AWS is really one of the core subject and the core topic course service from the AWS that you'll be learning whether you are going for an exam of certified Cloud practitioner some architect exam or maybe some Pro exam this information remains common as well as exam exactly same for all of them so once you master and understand the theoretical part as well as the Practical part of it that's it you have to never learn it again that's the beauty about it so first of all thank you so much for showing so much of support uh to this series and let's just also keep uh one more comment Target this video holds a comment Target of 150 comments within 24 hour of the launch of the video I hope you'll be showing me the same support that you have been showing uh so far on the channel uh super excited about it but now let's go ahead and get started with IM am so the first thing that anybody should learn in the AWS is how to create user already in one of the previous video I have mentioned that nobody nobody should be having an access from the root account root account is just to create an AWS account and that's it you forget about it you rarely touch it if something goes seriously wrong then you only touch it uh maybe to get support from the AWS maybe some billing waver or maybe something else in most of the Cas you really want to create admins and want to go through with that route we will be doing practical for it but first let's go ahead and take down the theoretical part of it which is super important from the exam perspective and yes you might need to watch this video a couple of times the lecture is pretty long uh but we'll be having fun in that all right so let me share the screen iPad screen rather so this is all the thing that we'll be discussing in this particular section so first and foremost the identity and access management you'll be seeing quite often that people use acronym for this one which is I am very common in the industry of cloud and especially if you're working as a professional role in the AWS everybody will be saying give me an IM am user give me an I am account or something like that that's exactly means that they want to give uh they want you to give them an account for you so identity and what is allowed by them uh the whole idea is you don't just give them identity that this is your username and password but you also Al attach some policy to that account some accounts are specially designed to just monitor the things some accounts are specially designed for testers for developers what's the difference between them developers you may want to give them access of some higher compute power machines developers maybe you want to give them some less power compute machines uh it's really bio statement here but this is just a vag example I'm trying to give so it's all about identity that who you are like I have a hes account on my AWS account and somebody else is also joining let's just say Rahul he gets his Rahul account I do stuff with my own account he does the stuff in his own account what's allowed depends on what permission you are giving them maybe you are allowing them to access three or four Services somebody else is getting five Services 10 Services it's all like that so this is the core IM am architecture that I've designed in front of you and we'll be discussing about them so this portion is the user one this is actually the ID and password and this also can be done two types user one to use web browser to graphically log in into an account or maybe he's a programmer and want a programmatic access to the account so there are only two types of access which are available then you'll be quite often seeing about the roles then we'll discuss about the groups and then we'll discuss about the policy just a brief uh syntax about it roles are majorly assumed so you get it's almost like a hat you wear the hat and you become that guy so it's almost like a badge you sometimes wear a badge of CTU sometimes you wear a badge of of Team lead so if you wear a badge of Team lead you are only limited to team lead Powers if you wear a badge of CTO you wears uh the powers of the CTO so this is almost like that most of the time uh the roles are assumed by Services which are there in the AWS so AWS Services cannot automatically do the stuff you have to provide them permissions of that and that's where role is majorly used all right then we have groups and in the groups they are attached with the policy so for example let's just say there is an admin group and there's a developer group and there's a tester group so each group gets uh kind of a club you can say just like we have Society club and the college Club this is almost like a club once you have designed this group then any new member comes up you just have to identify that hey you are going to get into developers group you are going to get into testers group you are going to get into admin group the policies are recommended to be attached on the groups not on the individual the idea behind that is that once you attach the policy on the group anybody who is a part of group will get that uh powers or policies for example if you're part of admin you automatically get the admin privileges similarly in that case if you are looking up forward that you are part of developers as well as admin so you get both the powers you are part of both the groups so you get the policies or the powers of both the group so I hope that makes things uh really nice AWS ask you couple of questions regarding this particular subject that there is a user should I attach policies to it and the answer is usually no uh this is not the correct way of doing the things we always want to go with the groups and don't worry in the next video we'll do the Practical as well so don't you worry on that right now just keep the notes take the notes and we'll work with that so the whole IM am is about getting the user an account as well as the Privileges to do the assigned task or whatever he's meant to do for this you'll be learning about the group the role and the policy we'll study about them so group is a simple way to organize the user or you can say just like we have a college club or you are having uh semester and years you are in the first year so you get all the Privileges of first year you are in final year you get all the privileges so group is nothing more than that policy is something that defines the permission what you can do in the AWS account or what services you can actually use that's all defined by the policy by the way there is always one or two questions around the least privileged policy in the AWS almost all the exams this is all simply saying that hey give the minimum permission to the user to perform any task don't give them extra permission so whatever the bare minimum permission that it can barely do the job that's always the idea so if any question comes around always go for the bare minimum permission or they call it as least privilege permission policy very very common very famous in that so user uh can get permission directly or via the group so it's not like that user is not allowed to get get any permission or policy directly you can do that uh but it's not considered as a good practice and AWS is all about promoting good practices so they always prefer that you actually get uh policies to the group and then the user is actually attached to that group or is being made a part of the group I'll show you how to do that later on now uh roles roles are for delegation and are assume so for example you just keep the roles anybody who has the power can actually assume that role almost think it like as a one-day prime minister if you become one day as a prime minister whatever you do there that's official but after that it it doesn't once you leave the role of prime minister that's it you are no longer a prime minister you cannot use that similar power so that's what the roles are maybe you are a cloud watch you want to go into AWS for something but as a cloud watch you cannot directly go in into AWS ec2 machine so you have to assume a role you have to wear that hat that's a common terminology being used now with assumed role you can talk to other services so this is a common thing and when you'll be creating more such things I'll actually walk you through in my AWS account as well that there are so many roles whenever you spin up any Services their attached uh minimum roles are actually automatically spinned up as a part of that and um those Services assume that role and then make it a permission now some of the good practices which are asked in even in exams as well first of all the root user the email ID that you have used for the first time creating account that is actually your root user this is used to sign up for the AWS and it has all the permission and there is no way absolute no way to reduce down that permission you may see that it looks like you have reduced the permission it doesn't it doesn't do that any time uh so the only way to actually reduce the permission is not to use that more often so that's the way and you should also look forward for these types of things in the exams as well that rude user should be avoided in any given case you should not use that there it should also enable the MFA MFA is multiactor authentication I'll also discuss about that in this lecture only uh but make sure you are aware of that that this always should be MFA it is being asked quite a lot in the exams as well all right now once you have the root user then you simply go ahead and create new users from that now new users you can set uh as much as policy as you want by default there will be no permissions on that it will be an account which can do nothing absolutely zero yes this is also being asked in exams a couple of times now you can create around 5,000 accounts and more if your organization is much more although 5,000 developers uh who are actually using AWS account that's a lot already uh but maybe maybe for some reason you are building the next Google or something I don't know uh you can also get more than 5,000 but you have to make a request to the AWS and they can enable it it's it's crazy I've never seen any organization passing this limit but hey this is the soft limit it's not a hard limit in AWS you'll see quite a lot lot of time this thing being used as a hard limit and soft limit most of the things have soft limits now use policies and prefer groups this is a common statement I use obviously there is no other way for you to actually assign permissions it's just the policy and always prefer groups to be assigned now in the Amazon you are going to see one more thing which is Arn quite a common terminology being used it's known as Amazon resource name now in the Amazon everything needs to be uniquely identified whether that's bucket maybe a storage maybe a computer ec2 machines or maybe another services or anything that you're doing everything is marked with the unique resource name in this case known as Amazon resource name so whenever you're working as a job or anywhere you will find this terminology quite common that Arn what is the Arn of this service what is the Arn of this bucket what is the Arn of this file everything has a unique uh resource name uh so get it done uh in your heart that yes it is a common name and there is a regular name as well whatever you want to call it as file.jpg or PNG or ec2 machine as hey my machine one uh that's your regular name what you provide but internally in the AWS when you are accessing anything uh also with the programmatic access everything is Arn all right now let's discuss a little bit about the group although it is very very simple to understand but still I'll go through with you so let's just say as we discussed uh we have three groups or you can say three buckets the first one is admin the second is developer and the third one is tester now each of them can have either the same policy or different policy depends on you in this case obviously it makes sense to have different policy so this one has policy one this one gets policy 2 this one gets policy 3 so each of these policies are different and I'll show you in the next video that how we can actually Define the policies it's pretty simple you can see them either in the Json format or directly you can check mark tick tick tick like that or you can design your own custom as well but it's possible now add policy to the group this is a common practice policies are always always attach attached to the entire group and whoever is the member of this group who takes part in that he becomes a tester if you want to move it from the tester to developer you actually remove him from that group and join him into the developer group it's really simple just clicks and buttons and all of that uh user gets permission via the group not the individually that's always and again as I mentioned least privilege possible very common term you'll see this quite number of times in exam as well that assign least privilege policies and all of that in the CCP exam nobody's going to ask you directly for the privilege or find out the permission all of that but uh knowing them is fairly easy it's just a Json format you can read it almost like in English it's pretty easy okay another thing that comes up is IM am Ro as I mentioned roles are assumed by the user so it's almost like a badge which is just lying around there uh whoever has the permission to pick up that badge they can pick up that badge and they are now rolled at that so roll can be assumed by users or applications or Services Services by I mean to say the services which are there in the AWS applications means whatever the software you're building uh they can also assume roles users can also assume the roles uh no problem in that but you'll rarely see users assuming the role M most of the time it's the services that assume the roles now again same thing imagine becoming a PM for the one day so I will not repeat that and gain the permission of the role only uh one thing to note in the exam sometimes they ask you not in the CCP but in the later on exams that let's just say I'm an admin but I take the permission of a developer who has only the power to roll out a smaller ec2 machine let just say T2 micro or something will I be able to spin up bigger machine because I'm actually a part of an admin group no the moment you assume a role that's it your all of the previous permissions they are gone away now you are a new man so it's almost like that's always remember the new role that you are assuming you only get the permission or the Privileges or the the policy of that account only okay uh how does the IM policy look like uh policies are Json document in case you don't know it's a JavaScript object notation uh nothing big it it looks like this one so I hope you can see it here so the version is this one and it looks like effect allow it says S3 list bucket so you are only allowed to list the storage buckets and here is the resource which is Arn Amazon resource name is AWS S3 example bucket you'll not find anything with the example bucket it needs to be unique but just want to see that hey it's pretty simple it just says allow so it's allow list it is allowing the listing of the bucket so that's it uh nothing to be worried about on that part so uh implicitly denied uh this is also a common thing you should know about it in the policy everything is by default disallowed you are not allowed to do anything unless you explicitly say that hey I'm allowing you to list the buckets then only you are allowed to list the buckets when I say list the bucket that means you cannot add anything you cannot create anything in that list that's uh simply known as uh implicit denied you have to explicitly mention that you are allowed for this one okay uh policies can be identity based or the resource based uh for example in the identity you can also mention that if somebody assumes this role or is a part of admin he can do this this stuff or you can also make them a resource based for example uh this bucket is allowed to be view publicly only few of the services on the AWS actually supports this especially the storage actually supports the resource based policy uh but you'll see very few support most of the time it's identity based uh that's all and even the direction of AWS where it is going it's now very clear that they want to support only identity based okay uh AWS supports six type of policies no you don't have to memorize them you just need to know briefly some vague ideas about what they are and by the way this screenshot is taken directly from the AWS documentation as well so that we can have have a discussion on what these are have a vague idea about them I don't worry this vague idea is more than enough to clear the exam so uh the six type of policies that it supports is identity based policies resource based policies permission boundaries really interesting organization service control policy this one is interesting and it's little difficult for people to understand this at the first go but don't worry uh we'll talk about this one then we have access control list and session policy okay now it's time that we Deep dive into them each one of them uh you'll be asked very basic questions around this one but it's good to have the knowledge around it so let's go ahead and work on with this one so this one first of all says identity based policy very simple to understand no need to dig deeper into this one you have simple users and group you ask them hey you can do this you cannot do that by default everything is not allowed so you allow them that hey this is what you can do this is just identity you give an identity to an user then is the resource based policy uh this is is rarely uh the most common examples are as I mentioned is always in the S3 buckets like this bucket will be public so no matter who you are this bucket is publicly visible to everyone uh so it's resource-based policies uh Grant permission to the principal that it is specified in the policy uh you don't need to go through with too much of that too much jargon is written only thing is it's uh they are all saying example is the best in awss 3 but I have not seen much of the resources a AWS supporting resource based policies so uh basically you attach the policies directly to the resource instead of the Identity or a user that's it then we have permission boundaries the policy defines the maximum permission that the identity based policy can grant to The Entity but do not Grant the permission this is the most common one we need to actually clear this one so there is a concept in AWS known as permission boundaries this is a common when you have organizational units uh what happens let's just say this is a big organization we have 100 developers 100 testers and then we have some of the companies that our Maj that our parent companies has bought in now we want everybody to use AWS our developers tester and the company that we have bought in so uh that was an acquisition uh really common these days so what happens is we give an organizational Unit A subunit of our a account to the developers a sub account to the testers and a sub account to that company that hey use all the resources now in that you can actually give the permission boundaries the most interesting thing about the boundaries is boundaries don't set the permissions boundaries only allow you that what you can set for example uh boundaries only mention that you can actually give the permissions uh related to ec2 but boundaries also can mention that you cannot give anybody permission to uh maybe be stock so you can give the permission to the ec2 accounts but you are not allowed to give any read right whatever the permission regarding the bean stock uh this is just setting the boundaries not setting the policies itself really common so make sure you keep an eye on this one do not Grant the permission this is the line which actually makes you clear the exams okay uh then comes up the organizational SCP so same concept goes for this one as well it's an AWS organization service control policy exactly like permission boundaries but uh this is like AWS organizational unit so in the permission boundaries you actually use that in one account only but just to give you an example to make you understand I gave you an example of organization this is exactly that so you have one main account you have multiple uh sub accounts of AWS uh so SCP again same thing it limits the permission but do not Grant the permission they are only like what is allowed to be given as a permission what is not allowed to be given that permission so they are not policies in itself they are uh limiting permission Frameworks you can say then we have ACLS uh ACL we'll study more about quite a lot in the series and in upcoming videos as well Access Control list so uh this is really interesting aclr cross account permission policy so what happens is uh you can actually go from one AWS account to another AWS account in the organization so organization SCV organization are really fun one so uh maybe one user actually leaves one account another account you want to go for that so ACL is the thing which allows the cross account permission so this is the keyword right now this is more than enough for you when we'll be doing Advanced courses in AWS and obviously that will come on YouTube as well uh then we'll discuss more about ACL as of now for this very first exam just remember ACL actually controls the cross account permission policy that's it that will clear your exam after that there is a s session policy as well AWS API to consume a role uh these are moreover programmatic access so session policies limit permission for a created session but do not Grant permissions yeah really important so if we actually drill it down uh this thing is actually not for permission but for controlling who can give permission or what permission SCP same and permission boundaries are same the only way to give the permission is either resource which is rarely used so only way to give the permission is identity based so that's what it is okay uh you are asked majorly the questions in the AWS CCP exams regarding uh sometimes like organizational SCP all always remember that its uh role is to limit the permission uh within the account do not Grant the permission so that's it uh rest of them are pretty uh not being asked much but you can learn about them if you want to go for okay uh remember as I mentioned earlier there are two ways of how you can actually uh give uh any account any permissions like that yeah these are little long lectures but I really want to cover a whole lot of things in one lecture only Okay so so there are two ways of how you give any permission or access to an account the first one is AWS console and the second one is AWS API it is being asked in the questions quite number of times that I want to give somebody a programmatic access so what should I do uh you should create an access key and secret for him that's all these are also like passwords a username and password but these are really long string don't worry I'll show you that how does they look like in the next video we'll actually go through with all the Practical of this one which is required not all but what is is required uh in the AWS console management you give them the uh username and password but it is also recommended by the AWS that you give them some of the MFA token a multiactor authentication token uh maybe u a USB drive maybe a OTP on mobile uh maybe authenticator something this is the core policy of AWS authentication uh you know about it you have it or you are so this is a common VI of how we are doing and maybe in the future we have more don't know now so you know your password so this is the first step of authentication when they say multiactor authentication that means I'll use multiple factors to authenticate you the first one easiest one is what you know you know your password so that's who you are uh then we'll verify you based on what you have so first time you registered and you say I have this mobile phone or I have this USB key that means you should always have this one so this is this comes in variety of flavors authenticators where you can send otps mobile phones USB it's pretty common even in some of the sensitive organization it's very common that the developers or whoever have the AWS access they carry a USB uh within their key fobs or something uh very common these days it's actually moving into the mobile that you have authenticators or a mobile phone where all the otps comes and then only you can log in uh very soon you'll see that there are a lot of things which are actually using fingerprints and the face recognition this is not there in AWS as of now uh but who knows they are actually progressing quite a lot uh so so maybe in the future so right now you have two Factor authentication only maybe who knows one day we'll have three Factor authentication it's getting crazy now one thing I would like to discuss uh from the exam perspective is service control policies because sometimes there are questions that actually comes around SCP the idea is again same if you go back idea is again same if you have this SCP uh the organization SCP it limits the permission but it do not Grant the permission if you remember this you'll never fail in any question regarding to that but let's just say we want to have a scenario of that a very common scenario this is a management account this is the account where you have signed up this is the root account and root account can also have scps but they do not Grant any permissions for that but there's no point of having anything on the root it's just allowed to do everything so let's just say you have two groups in your company one are Developer one are tester and maybe another one that you have acquired another acquisition so for the developer you are writing an SCP that only create 5 ec2 so you not actually giving them any permissions or anything you can only you are mentioning that hey you are only allowed to create 5 ec2 Machines of this type maybe T2 micro I don't know who spins that kind of machine uh apart from demos but you are only allow thing so you're not saying that hey who can create that you can just create users and they can spin up their machines you can make them admin whatever you can mention the Only Rule that you are mentioning that you're only allowed to create 5 ec2 machine so this policy will automatically uh get in action as soon as somebody creates more than five machine in this account so the moment they have five machine the six machine automatically this policy will trigger and will say hey this account is not allowed to do that because the main root account has created an SCP uh for this one service control policy you are not allowed to do that uh you might have seen this kind of a thing in a lot of sandbox account a lot of companies these days actually offer that hey we'll give you a free AWS account in which you don't have to worry about any bills it's on us uh basically they are actually governed by the SCP so any new user who creates an account they are allowed to do only certain task not the full task same goes for the testers let's just say testers are allowed with two ec2 instance that's it you get the idea this is only a framework you don't apply the details of it my new details are not there so again let's summarize this uh together SCP do not Grant permission we never granted any permission in this developer account like you can create an ec2 account or not that's the job of the account itself we are only saying you are allowed to create 5 ec2 so they do not Grant the permission they control what permissions are available to be granted for any organization un available so when I say that hey uh let's just say I say you are not allowed to even touch the S3 bucket that's it that policy will not be shown in this account that's it uh let's summarize this by having some of the IM am best practices and then we'll call it a day first of all use MFA multi Factor authentication uh rotate the keys and password very common for the security Concepts that hey rotate your keys or password whatever you have in X days X could be depend on your uh organization 90 days 180 days whatever that is uh do not use uh root account I forgot to write a use there uh do not use the root account in any case if any question is there no matter how tricky it is no it's a straight no no we don't use root account always go for least privilege permissions it's always being at least one time asked either on the root account or in the per least privilege account in your exams uh go for the least possible privilege permission and uh there's also a tool known as IM access analyzer in the AWS uh no you don't need to learn how to use it as of now you just need to know it exist the whole idea is the name actually makes it pretty easy to understand that I am access analyzer Analyze That hey are you giving more permissions to this account than they require uh although it barely does its job I never found it actually truly immensely useful but it does the job it does the job sometimes it's just a tool to actually generate the least privilege policy based on the access activity uh remember it works on the access activity what you are accessing commonly and frequently that's why it's it fails many times anyways uh regularly remove users roles and permissions and policies and credentials and whatnot which are not in use do not remove the guys who are on a break for a 7day or a holiday and do not remove them uh they are Al all good to be there but what are being not used or the GU is no longer part of your organization something it should be removed periodically usually in the organization there is a periodical check or maybe in a quarter or something in which we reevaluate that hey whoever is using the resources can we shrink down some of the resources or if there is somebody who is gone uh let's just remove that account although it would be ideal that uh whenever the user left that organization you remove its AWS account some organization do follow that but I have rarely seen such organization mostly it's a quarterly review in that everybody just flush off them anyways uh you can also make the conditions like IP range or geolocation on the user access also that you can only access AWS within our company only or within this laptop only it's totally doable uh geolocation specially is used quite a lot but uh it depends on what sensitivity level you are working on I have not seen anybody actually uh putting a geolocation because I never happen to work in such environment but hey its option is there right in front of you all right so quite a lot uh that we have discussed almost a 30 minute uh but this is all about theoretically you need to know about uh IM am uh regardless wherever you are preparing this is all this is all it no matter what extreme exams you go this is all that you need to know now in the next video we'll go through with actual a practical Hands-On uh the demos uh which are required I think it gives really a great boost but in the CCP I've seen many tutorials and many people teaching just with the notes and everything and you pass the exam with the flying colors but I think I think that uh there should be some practical so you get confidence in the AWS and all of that uh we'll be doing that in the next video so let's go ahead and catch up there don't forget the comments Target if you haven't hit that subscribe uh go ahead do that I'll surely catch you up in the next video

Channel: Hitesh Choudhary

Views: 10,068

Keywords: Programming, javascript, devops, cloud, aws, reactjs, nextjs, MERN, coding interviews, certified cloud practitioner

Id: XgLctgRh_7g

Length: 30min 30sec (1830 seconds)

Published: Sun Feb 04 2024