AWS For Front-End Engineers, v2

Securing Root Account with IAM

Steve Kinney

Steve Kinney

AWS For Front-End Engineers, v2

Check out a free preview of the full AWS For Front-End Engineers, v2 course

The "Securing Root Account with IAM" Lesson is part of the full, AWS For Front-End Engineers, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve navigates to the IAM section of AWS and creates an new user with administrator priviledges. The admin account will be used to work with AWS instead of the root account for security purposes. The admin user also has API access.


Transcript from the "Securing Root Account with IAM" Lesson

>> The primary way that you manage users in your AWS account is something called IM, which I don't know that's supposed to be clever but it's identity access management. But it also feels like I am this user. That could not be a potential pawn or not. Who knows?

So it's got simpler over the years. Before, you'll notice that the root user has no API access currently, right? And that's good. That way you don't have to worry about accidentally pushing the root users key up to GitHub. And in a public repo, exposing it to everyone because at this moment, the root user does not have an API key for you to push up into GitHub and exposed to everyone.

So that's one way to solve for that. But you can see that there is a security recommendation here that you should absolutely follow. And it would be irresponsible for me to be but for us, it doesn't matter, right? Because if you set this up now and you forgot about it, you'll be sad later, right?

So we will go ahead and set this piece up both for a root user and again later for our administrator user. Our goal is to set up this root user secured as much as possible. And then never touch it again, right, because that way it's there in case you lose somehow, so might lose control the measure account, what have you we have one additional tier but this is not the one we go.

Writing the password on sticky notes for, right, that's our regular account that we do that with. So let's go ahead, we'll add the two factor here. We'll kind of take that as a personal trip together and then we will reconvene and talk a little bit about setting up that administrator account and so on and so forth.

One thing that we talked about during the break was to add two factor auth you need some kind of mechanism. That could be a Yubikey. That could be all sorts of things. There are also a bunch of apps that will store your two factor auth codes, Google Authenticator being one.

I use Authy which I actually used before I worked at Twilio, I think before Twilio even acquired it, but then I worked at Twilio. So that is a no way. The reason why I use it, it's also great. It's just the one that I happen to use and can vouch for, but I'm sure Google Authenticator and some of the other ones are also great as well.

So got that set up. And you can see that now I've got effectively two checks, right? That said, I still don't necessarily want to use this. User if I can avoid it, right? I'd rather create administrator user that I can use for most things. And then eventually, as I get a little bit more granular with the different use cases, I again, if I make a GitHub action that can push my client side assets.

It should only have permission to push the client side assets to the. That's the ICD process should, right? So I can get really granular with the general permissions, I give a very given user. But step one is kind of go ahead and create myself a new one for me in this case.

You can also see that there's an account alias that you can change. One of the reasons you might consider changing that, is right now for this account alias of 552306219397 that I have to type in, And just go ahead and click that and hit create, and then we'll do FCMAWS live for me, but for whatever you wanna do for you.

And now you will get, it looks like I tried that one already. I misspelled AWS but that also means that I will not have to deal with the conflict from the previous attempts at this as well, let's all just remember that, cool. So once I have that, I can go in and click Users.

And you can see that at this moment, there are no users to speak of. But I can go here I can add a user. Now you can give this user any name that you want. For my purposes of remembering things, I am not going to be particularly creative here, but yeah, you could use your name if you wanted to whatever.

This will be the general user for you the real effective administrator/owner of the account. Just gonna keep it somewhat generic at this point, then we have the two kinds of access that a given user can have. And this is kind of interesting, right? So you have the programmatic access, which remember your root user does not have, this is effectively API access.

So what are some things that we'd use the API access for? Well, API access right but also the command line, AWS command line tool, right, which you might use to, before we set up CICD. We might go ahead and just use the command line to take our build assets from our local laptop and deploy them up to production as well.

So that's one thing that you could set up a API access key for your root user. But even if you've gotten this far, and you're like, throwing caution to the wind you like, I'll just use the root user. There is yet another reason why you might consider putting together a administrator user of some sort.

We are gonna check both just so we can kind of get a sense of what that looks like. Even if you so, even if you don't think you need both, you go ahead and do that. So then we've got the ability to give it a password which I'm going to do in this case.

Obviously, if you were creating an account for somebody else, you might choose to use like an auto generated password or something along those lines. And you'd probably make them reset it at the next sign in. I am going to not do that in this case because it's just me, We'll go ahead and we'll figure out what permissions this account has.

So then we've got a few different options for figuring out what this user is allowed to do. As I mentioned before, future users that we're gonna make, should have as little access as and get away with. But somebody needs to kill the castle and it probably we don't wanna use the root user, so this this account will have what we call basic administrator access.

Which has access to almost everything but billing, which is why we set up billing back when we were the root user, which we still presently are. You can add the user to a group. You can copy the permissions from an existing user or you can attach the policies directly to the user.

We don't have an existing user, so that one rules that one out. We'll talk a little bit about groups later. Let's just put the policies we want right on to this user. And there are 725 results, luckily, the one we need is at the very top. [LAUGH] Right, and that is this administrator access, which is the one that we want to use in this case.

You hit the little arrow, you can figure out we can see in JSON, what it has the ability to do and we'll write our own policies later. But you can basically see what the administrator is allowed to do. It's allowed everything on everything, right? So that is what we're gonna use in this case.

If you wanted to scope it down a little bit more you could, like I said, for all the different things that you would want to do there are different kinds of pre configured sets of policies that you can apply to that user. We are going to stick with just administrator access for now.

Next ,we'll go to tags. Okay, tags are not something we're gonna deal with today. Where attacks useful, they're basically just metadata that you can put on anything in AWS, right? So tags are useful especially as your company grows, or the company you already have, like you might say, okay, this tag, we're gonna tag the team and it's such an such team.

We're gonna say the product is such and such product, the cost center is such and such cost center, so when you get that bill from Amazon, and somebody ran up a big tab, you don't have to like reverse engineer. What ran up the costs, right? You can also do clever stuff with programmatically with the API access.

You wanna get all the resources with yeah, okay, I wanna get all the resources with a given tag, so on and so forth. It's just ways to annotate various services and accounts, so you can figure out for either budgeting or stuff along those lines and add that metadata.

We don't really have a lot to do with that right now. Like I said, you look at the examples up there, you can add user information like an email address. Job titles, are figuring out who to yell at, in the case that someone ran up a bill or something along those lines.

Awesome, so this is basically what we've got. We've got administrator user, it's username, unsurprisingly is administrator. It's gonna have both programmatic access so we can use the CLI from our computers. You could argue that like, if you're making it for the team, then maybe you'd also make individual ones and just have that kind of master administrator user.

In case somebody decides that they're rich off NFT's and never come back, whatever, and let's go with something involving a boss but I felt really just not fun. So, we've got that, we can go ahead, we can hit create user then don't get carried away. You're like sweet.

We got a user, yeah.
>> What would you look for to figure out if your policies hindering you from AWS service if you set up different axes?
>> You will get like an access denied real fast, right? You will try to do something very simple and get yelled at, right?

I will probably at one point of time together mess one up when I start writing my own by hand. So you will quickly get denied at which point you will, the error messages for those are actually what some of the better ones that you'll see as well, cool.

Any questions in the room? All right, the screen, do not get carried away. It says success. You think you're done. This is important screen, see that secret access key, which I'm not gonna hit show on, your API. Your API Key has two parts to it. You have the access key ID and the secret access key.

Despite the fact that those names, sound shockingly similar. They are very different. Effectively the access key ID is kinda like your username. And the secret access key is kind of like your password, right? But you will get to see that secret access key exactly once. Right now that's somewhat of a lie, but effectively on the screen, you will see there's no way to go back into the AWS console and see it again later.

So if you just go and hit close, you will have to go regenerate a new one, not a whole new user. But you actually have to go into at least root in this case, since or I guess as the administrator and go generate yourself a new API key.

So you're I'm gonna hit the Send Email button. That's not even worth it. It opens up your email client, telling the person that they have an account now. Especially if this is you, it's not super helpful, it doesn't include any of the requisite information that one would need is go talk to the person in charge or something that you are the person in charge.

So your choices are, go ahead and hit show, which I'm not going to do. And then go put that in like your password manager of choice or some more securely place, somewhere encrypted. The other option is you can hit download CSV, which is gonna download a CSV that has this unencrypted in it.

So like I said, you can probably just hit show. In so far that I am live streaming my screen and this account effectively has the keys to the castle, I am going down with the CSV, with that you can go ahead and hit close, right? And so, there's your new administrator user.

And to kind of think about the question, I got earlier about what happens if you mess up the permissions. If you get too low, you can always adjust the permissions, right? You've got the root user that has that kind of super user access almost to your account. You can tweak and add the policies for your administrate user or any of those other users.

Like I said, at one point if I don't do it on purpose, I will at least accidentally probably mess up one of the policies and get yelled at. So we've got that in place from here you can also see last activity so on and so forth and yeah, effectively at that point we're done with this root user for the day.

We are going to log out of the root user and go in and switch over to our administrator user for a little bit. So with that, you can go grab that, you actually hit this copy button as well. The sign in URL, will do that and what we will do is, we will sign out and we will kind of go through this process again with our admin user.

I'll kind of get us there and then we'll take another quick break and we will add the two factor off. And all that kind of stuff is kind of an exercise to go through it one more time. Also just to secure our accounts, and then we will kind of pick it up from there.

So let's go get that piece in place. I'm gonna go up here, and I'm gonna sign out. I'll put in that URL, you'd also type it in, if you missed it or your 12 digit account, and this case I am, Sure, great, and so as you can see, I kind of joked before, places I've been to, as the root user have shown here, it's local storage.

It's fine. But that also means that I am is there as well. And you can see that it's making sure that you did set up that MFA on every user, which we did because we were responsible. But now you should also add it for yourself as well. And like I said, I would be remiss if I said, no, no, this is just a course.

It's cool. It's cool. It's just, not do it, let's go, let's actually secure these accounts and do it right. We'll add the two factor auth to our administrator accounts, and then we'll get rocking and rolling.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now