Demo: Identity and Access Management (IAM)

In this video, I'm going to demonstrate the basic configuration of I am in my AWEX account, but before I get started, I just want to point something out quickly. So here I am at the home screen of the AWB management console. And up here at the top, right. I have the ability to select the region. Now, if you're following along at home, it's important to stay consistent with your AWB region. And so what I'm going to do is choose a region that's geographically close to me. I'm going to choose U.S. East Ohio, but will you want to do is make sure that you're consistently choosing the same region as you do these live exercises, because some of the things that you're going to build are going to need to work with other things that you build. And if they're not in the same region, that's not going to happen. Now, the other thing that I'll just mention is that there are different services available in different regions. And so if you are planning on following along at home, I suggest that you also choose the Ohio region so that you can be sure that everything you see me do will be possible in your AWP console as well. Now, the other thing that I just want to mention is at the moment I'm logged into my Adewusi account as my route user, so I'm logged in as not and I am a user, but a route user. So I'm going to go to services and I'm going to just simply type in. I am. And go to identity and access management. And it's basically walking me through a series of steps that I should do here, so No. One, I should activate multifactor authentication on my route account. And what I want to think with my route account is basically this is an account that can do absolutely anything inside of this AYSO account. So. I need to be careful here. I don't want to allow somebody else to potentially get this rude account credentials. This is a very, very powerful account. And so one of the first things that it walks us through is actually activating multifactor authentication that way if somebody does get their hands on my username or password. They still can't access my account unless they also have my multifactor authentication device. So before we move on and start setting up multifactor authentication, there are a couple of the quick things I want to show you here. You can see a link that you can provide to your erm users. So we're going to start creating other users here, other erm users. I can copy this link and give it to those users and then when they hit this link they're hitting this particular AWADI account and they can sign in with their erm credentials. So that's a great way for me to give them a direct link into this account so that they can sign in to the console. As an I am user, I can also click on customizer. And I can create an account alias, so for my account alias, I just put in a Rick Quraishi demo and I'm going to click on Yes, Create. And there we go now I've got a nice friendly you R-AL Rick Ricci demo not that was done Amazon.com console. And so I can provide this sign and link to any users who want to sign in to this particular HWC account. OK, so now let's starting to go through this little ordered list of what AWI wants me to do from a security perspective, for I am so for my account, I'm going to click on Manage MFA. And what it's telling me is I'm accessing the security credentials page for my Adewusi account. And it's a best practice for me to use I am users, so I'm using the route account. This is not really the account that I should be using on an ongoing basis. That's basically what it's telling me here. They're trying to encourage me to set up I am users. But at the moment I just really want to set up MFA on my route account. So I'm going to do that. So I'll just check. Don't show me this message again and continue to security credentials. And then I'm going to click on MFA. And I'm going to click on Activate in My Faith. And I'm going to be using a virtual MFA device, so my particular MFA device is Google authenticator on my smartphone. There's a bunch of different options that you have available to you. You can use virtual MFA devices like a smartphone app. We could also use a YouTube security key, which is a little hardware device that we plug into a USB port. Or I could use some other hardware MFA device. These are produced by Gemalto, but they're probably pretty similar. If you've ever seen RSA tokens and key fobs, they're very similar to those their physical hardware devices that generate pins that you can use for an MFA device. I'm keeping it very simple. I've got the Google authenticator smartphone application installed on my smartphone, so I'm going to choose that MFA option and I'll click on Continue and then I'm just going to go ahead and launch Google Authenticator. And when I launch it, there's a little plus button that I can click on to scan a barcode. And so I'm just going to expose this QR code here in the console and then I'll scan it with my smartphone. And once it's in my smartphone, it'll present me with multifactor authentication codes. So I'll put in the first MFA code that it shows me and I'll just wait a little while and whatever the second MFA code comes up. I'll go ahead and put that in and I'll click on Assign MFA, and that is essentially pairing this AWB account with Google authenticator on my smartphone. And so now I'll just go ahead and hit close here. And I'm going to go back to the IBM dashboard and you can see it's put a nice little green check next to this activate MFA on your route account. So if I now sign out of the AWADI console and I go ahead and attempt to sign back in. There's my username, there's my password, I go ahead and sign in, it is now prompting me for an MFA code that I can get from my smartphone app and it changes every so often. As a matter of fact, it just changed as I was typing that. So I'll put in the latest and greatest MFA code here. I'll submit. And so now I can't sign in unless I have not only my credentials, but also access to this physical device as well, my smartphone. OK, so I'm just going to go ahead and go back to the erm console here. OK, so now I'm going to move on to the next step shown here. I'm going to create individual erm users and I'm going to click on manage users and then I'll just simply click on add users and I'm going to add a new user called Rick Kuraishi. Now I could add groups of users, but at the moment I'm just going to add a single user and I'm going to give this user programmatic access and AWB management console access as well. And the programmatic access is going to enable this account to use things like the API or a software development kit to programmatically manage the resources in this console. And I'm also giving AWEX management consular access, which is exactly what we're using right now, the AWB Management Council. And they'll go ahead and establish a custom password for my user, and I'm not going to force this user to reset their password the first time they login because this user is going to be me. But if it was somebody else, I would force them to change their password at the next login. And now I have a few different ways that I can assign permissions to this user. So if I've already created a group that has all the permissions that I want to grant to this particular user, I can just simply add the user to that existing group and they'll get all the permissions that that group has. And here you can see something new. We have the ability to set a permissions boundary, so if I have a user who I only want to be able to manage certain features like, let's say S3, for example, I can create a permissions boundary that dictates that no matter which policies this particular user gets, no matter which groups they're added to, there's a boundary. They're only going to be able to manage S3 and that's it, even if other policies are assigned that give this user additional features. So I'm not going to create a permission boundary in this case and I'm not going to join the user to a group yet. But we could also possibly copy permissions from an existing user. This is a brand new account, so I don't have an existing user. So what I'm going to do is I'm going to attach existing policies directly and this is going to be my administrator account. So from this moment forward, I'm going to stop using my route account to manage this Adewusi account. I am now going to use my IAM account to manage this AWG account. So I'm going to grant this particular account administrator access. And here you can get a quick look at the IAM policy, basically saying allow everything, the stars, my wild card character. It's allowing me access to do everything. So this is an administrator account that is basically unlimited, can do whatever they want. Now, before we move on, I just want to back up here a little bit and I'm going to uncheck the administrator access policy. And I just want to show you, there's all sorts of policies that are already pre generated here. Like, for example, here's one for S3, Amazon s three full access. And if I want to, I can expand any of these policies and I can take a look at exactly what these policies are providing. Like this one, for example, is providing full access to S3. And I can view the details of the policy here in this JSON formatted policy. So that's what these policies are, are essentially sets of permissions that are available to this user. And as you can see here, there's a whole lot of these pre-built policies that automatically exist. And I can just simply choose from when I create these I am users. And for many of them, we can just simply expand them. We can look at a summary of the policy. And we can look at the JSON formatted text that makes up that policy, so like I said, for this particular user, again, I'm just going to search for administrator. I'm going to grant this user administrator access, and then I'll go ahead and click on next tax. Now, here you can configure tags to organize my users. And if I want to use tags to kind of keep things organized inside of my AWG inventory, I can do that. So what I could potentially do is use tags to just kind of keep things organized and make it easy for me to query certain things. And so, for example, if I wanted to hear, maybe I could add a key called location. And this particular user is located in New York. So I'll just put in NY and I could just create whatever tags I want. These are just ways to help me keep things organized. And then I'll just go ahead and click on review here. Here you can see my user. What type of access this user has a type of password they have, whether or not that password reset is required and what the policy they have been granted is. And I'm going to go ahead and click on CREATE. Now, if we take a look at this user, we've got an access key and we've got a secret access key. And I could click on show here and show that secret access key. And I'm not going to do that because I don't want to expose that secret access key to this recording, because these keys are what the user is going to use to programmatically access this Adewusi account. So if anybody were to get their hands on this access kid and the secret access key, they could use those to programmatically do anything that an administrator could do inside of my AWG account. And so I don't really want to do that, and I don't want to expose those account credentials to everybody who's watching this video. Then I can also click on this little download CSFI button, and this is going to download all of the user's credentials into a CSV file that I can then open and view. And so here is a look at the contents of that CSFI file, as you can see, have Xed out the secret access key, but it's going to show us the console log link, the access code and the secret access key along with the username and the CSB file does not contain the password that we created. And then the next thing I could do here is if I wanted to email the login instructions to user, I could click on send email and send the login instructions that way. So that's it. Now, I've created my I am user. And what I'm actually going to do here is go ahead and sign out of my route account. And what I'm going to do is go ahead and put my new You URL with my account into my browser. And go ahead and go to that particular Awista account, Sinon, and from there I'm going to sign in as that I am using that I just created and I'll put in my password and I'll go ahead and click on Sign in. And there we go now I'm at the AWB Management Council, so it looks good, looks like my imposer worked properly. So if I go to the AMP page, you can see it looks a little bit different here right now. I've created an individual erm user, so I've got a green check there next to that one. So now I am basically done with my rude account, I've created an I user that gives me administrator access, now's the time to stop using that rude account. What I'm going to do is I'm going to take my MFA device and make sure I have it somewhere that's physically secure and I'm not going to use my route account for anything moving forward unless I absolutely need to. From here on out, everything is going to be managed by I am users. So now my next step here on my little list of steps here is to start to utilize groups. So rather than create individual users and individually assign them permissions, what I can do is I can choose create a new group and I'm going to create a group called Administrators, and that's going to be the group that I create. And everybody in this group is going to get this administrator access policy so I can just choose again. Just like when I saw I created a user, I had this massive list of potential policies that I could apply here. I'm just going to go ahead and assign this particular group administrator access, hit next step and then create my group. And so now I've got a group called Administrators, and I can simply click on Add users to this group and bring my user, Rick Quraishi, into this group. And so now this I am user is going to get all of the permissions that are included in this group. So now I can go back to this individual user and if I want to, I can remove the permissions from this particular user. I can detach policies from this user because the user doesn't need policies directly attached to it. All right. So now my user has the permissions that the user needs based on group membership. So, again, if I go to my groups here, I can go to administrators. I've got a user called Rick Kuraishi in that group. And Rick Croci still has administrator access based on that group membership. So now it's really easy because if I need to create a new user, I can just go to my group, I can click on the administrators group and I can click on ADD users to group and I can find new users that I want to add to this group there. And I can just simply create new users if I'd like. So let's go ahead and create a new user. I'm just going to call this user demo. No permissions. I'll give it console access and I'll go with an auto generated password here because I'm just going to delete this user when I'm done and now I can just simply pick a group for this user to be in. I'm not going to assign any tags and I'll just create this user. Now, I don't have to actually assign any permissions to this particular user. I can go right back to my I am dashboard here. And I can look at my groups and I can go to my administrators group and there's my new user demo, no permissions. And that user has been granted the administrator access role based on its group membership. So I'm just going to go ahead and delete this particular user here, demo, no permissions. Click on yes, delete and get rid of that user. OK, so let's go back to the IBM dashboard here. And then last but not least, I need to apply and I am password policy, so I need to basically govern what sort of passwords are going to be acceptable. And minimum password length is six. I'm going to go a little bit bigger than that. I'm probably going to go eight or higher. Typically, I will do actually ten or higher in an actual production environment. I'll always require uppercase, lowercase number and non alphanumeric characters because I want these passwords to be highly secure. Users can change their passwords, but they have to comply with all of these policies. And I'll also set a password expiration date. Let's say we make it 60 days. I don't want people to be able to use their last five passwords, so I'll go ahead and set that option here. And if their password expires, are they able to reset it or does an administrator have to do it? I'm going to go ahead and leave that unchecked. And so those are some kind of typical settings that I would do in a production environment. In reality, I would probably make my minimum password length 10. I know it's a bit of a pain for those users, but it's definitely more secure because this is just a demo environment. I'm going to be a little bit more relaxed. I'm going to make it eight. And I'm also not going to force passwords to expire either just because it's simply a demo environment. Now, that being said, this may be a demo environment, but if somebody manages to get in to my demo environment, they can do all sorts of stuff. They can incur all sorts of charges. And I'm responsible for those. So even if you're just playing with an AWB account to get a little experience, it's still extremely important that you keep it secured so that somebody doesn't take over this account, run up a bunch of charges, and then you're left with the bill. So now that I've created my password policy, I'm just going to go ahead and go back to the IBM dashboard and look at that, everything is nice and green, have green checks. So now what I'm going to do is I'm going to hide that MFA device for my route account and I'm going to make sure that my route account is no longer used. Route account is really best practice. It's kind of a day one thing. You use it, you set up your account, then you don't use it anymore unless you really need it. But now I have an administrative user that I can leverage, so there's really no point for me to continue to utilize that route account. So let's go back to the user screen and under my user, Rick Qureishi, there's just one other thing I want to show you. I'm going to click on this user and I'm going to go to the security credentials tab. And here we can see the assigned MFA device so I can click manage here. And just like you saw me do with the route account, when I'm going to do is I'm going to go ahead and associate an MFA device with this user as well. So in the exact same way that you saw me do with the route account, I'm going to use my smartphone application here. I'm going to associate it with my smartphone using this QR code that you see right here. And I'll put in the first two codes that are presented to my smartphone app. And now I've also got my on my account associated with the multifactor authentication device. And again, this is important because this particular I am account is an administrator. So the administrator can basically do anything they want to do. And so it's critical that I have multifactor authentication associated with this user as well.