The underlying AWS mobile CLI used in this course has changed it's API. If you're starting to learn AWS, you may want to try the latest course. We now recommend you take the AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course.
Transcript from the "AWS Account Setup & IAM Role" Lesson
[00:00:00]
>> Steve Kinney: So the first thing we need to do is we need to create a user to use these AWS services. Now, you can go in and sign up for an AWS account but generally speaking just using that account is considered bad practice. Why? Cuz that is your main account.
[00:00:15] That is the account that controls all your billing information. It is the one source of truth for all the things that you control. If, for instance, those keys leak cuz you accidentally push them up to GitHub or somebody else accidentally leaks them, that's problematic. So what AWS recommends is creating a sub user that you use most of the time.
[00:00:33] For those of you who are familiar with Unix, a lot of Unix machines, including MacOS machines, have a root user that we don't touch or use. You have another administrative account that uses it. And you can use pseudo or another tool to tap in to those administrative super powers as root super powers later on, but generally speaking with great power comes great responsibility so we tend to stay away from those.
[00:00:58] So the first thing we're gonna do is to simply get this out of the way. We're gonna set up the sub user that we're gonna be using for most of the time. So if this is your very first Amazon account, we're going to create the sub user. If you are familiar and you've used AWS before, you may already have a user that you use separate from your root account, that's totally fine.
[00:01:17] You can make an additional one just for some of the tools that we're gonna use today. You can use that account as well. But if you have a brand new AWS account and this is your first time, we do need to make one additional user. So we'll flip over to the AWS console and take a look at how to do that.
[00:01:37] First step in the very beginning. If you go to the Services tab, there are a lot of tools that Amazon offers. So you can see that by their categories, ProTip is you also can hit A-Z if you're just looking for something in particular. You can see all the ones that start with the word cloud for instance, they're not related.
[00:02:00] I'l pull it back here, normally I tend to have a good sense for what I'm looking for so I use the search box. If we want to create users, we use this things called IM which is identity and access management just type in IM here and click.
>> Steve Kinney: Cool, so there are a few things to do to kinda keep your account secure.
[00:02:23] These days, if you have a brand new account, they didn't provide you with any root access keys because using your root account is a bad idea. If you have an older account, you might actually have some root access keys. You can go in here and delete them cuz we're going to create another user to use as well.
[00:02:38] The other one is activating multi factor authentication is something that you should absolutely do. We're not gonna do it in this workshop, but it involves basically going through using some kind of multi factor authentication app, whether that's Authi, Google Authenticator, so on and so forth. The one that we care about is Create individual IM users.
[00:02:56] This allows you to create multiple users with different levels of access to your account. You might have one that has administrator access, that can do all sorts of things. You might have another one that, for instance, if you're using continuous integration and continuous development, you might have one that has only access to the AWS services that that user needs, that tool needs to be able to do its job, right?
[00:03:18] So the idea is like kinda the principle of least access. You wanna give everything just a bare minimum of privilege that it needs. So this allows you to create many different users with different levels of privilege. Because there's a case where you could, for instance, use your key for, again, some kind of CI tool.
[00:03:35] If they have a security breach, well, the worst case scenario is it's only allowed to upload like S3 or change CloudFront configuration. It doesn't have access to your billing information or the ability to spin up a whole bunch of EC2 instances for Bitcoin mining, right? You can at least limit the scope of damage.
[00:03:51] If it was your root account, well, that's going to be a long and awkward phone call with American Express later as you try to rectify all of those charges. So to create a new IM user, we're just going to go to Users. You can see that I have one that I created earlier.
[00:04:06] Again, if you have an account, you can use that, otherwise you can go to Add user and you give it a username. This is any username you want, usually something descriptive is very helpful. As someone who has made plenty of non-descriptive names, the name that totally makes sense to you now probably won't make any sense to you in three months.
[00:04:24] So generally speaking, if I'm using one for Travis CI, I'll probably just call it Travis CI so that if I do need to change any of those permissions it's very easy. So I had one called Mobile Hub which I'll actually be using, but I do wanna take you through the process of creating a new one.
[00:04:37] So we'll just call this one Administrator. And you have these two check boxes, one is programmatic access, it's the ability to make API calls from the command line tool. Again using the CI example if you wanted to push S3 if a bill passes on master, you would use an API to do that, that all happens with the programmatic access.
[00:05:00] The other option is the AWS management console. This is the web user interface that I'm using now. So you can make different accounts, some that can access it through the API or the command line tool, others that can use the web user interface. If you're just using it in some kind of program, clearly you would only use the programmatic access.
[00:05:19] If it is one that people are planning on logging in on. And you might have one AWS account for you but also the company you work with might have an AWS account and they might provision many users as well. So depending on your use case, there's a right choice.
[00:05:32] If you don't know, guess what? There's one additional choice, both. So you can click both. If we look at programmatic access, you can see that's the only option. If we click on AWS Management Console Access, there's the ability for an auto-generated password which provide a custom password and then prompt a new user to change their password immediately.
[00:05:51] If you're creating this account for you, then you probably don't need to change the password, right? You've made the password. But if you're creating the account for somebody else on your team, well, they don't want you to know their password, so they would be prompted immediately to change it.
[00:06:04] Here's your one-time password to get started, and then change your password. You can provide a password, so on and so forth. For us, we actually already have an account but we'll create a new one and we'll actually give it both and I'm gonna say custom password. I'll just,
[00:06:22]
>> Steve Kinney: And I don't need a new password cuz it's just me. The next is permissions. What is this user allowed to do? Now again, depending on the size of the group you're working with, if it's just you, you can usually attach policies directly. But if you're putting together a team, you might have a group of all engineers that work on such and such product have this level of access, while people in ops might have a different level of access.
[00:06:47] You can create groups and put the users in there. It all depends on what you're trying to accomplish and level of scale like this is probably the right choice. But for us, who are just getting stated on kind of just using our own personal account, we'll just attach policies directly.
[00:07:01] The other options is obviously copy permissions from another user, be like whatever Sherry has, I want Claire to have. So on and so forth, right? Both of those are options. If you find yourself doing that a lot, you're probably better off making a group cuz that's effectively what you're doing at that point.
[00:07:18] Cuz then you could also change the permissions of that group and then everyone in that group will get the new permissions. So we're just gonna attach the policies directly for this user, and there's a whole bunch of options. You can see there's stuff as wide ranging as administrator access, right?
[00:07:34] Which is kind of pretty much everything, not everything, but pretty close. To Alexa for Business Read Only Access, right? A lot more specific. This is not an account that can go even changing things. They can just read and pull down that information in your application. That might be something you're writing an app that's going to pull down this information.
[00:07:53] You would give that app, you create an IM user for that app and give it that level to pull down. For the mobile hub stuff that we're gonna use today, it's actually gonna touch a whole bunch of different APIs. So we're actually gonna give it administrator access. But you can actually go through all of these in your copious free time, pick the right choices.
[00:08:11] You can actually create your own policies as well if there is something that doesn't actually match your exact needs. So with that in place, we'll go to Review. And so we can see the user name, it's Administrator, providing programmatic and console access. We have a custom password that we're not gonna require a password reset.
[00:08:27] And the managed policy is Administrator Access. We'll go ahead and create that user. A few things going on, not a lot. You can see, here's our new user. Send email might look like yeah, I wanna get this secret access key and access ID sent to me via email.
[00:08:43] That's just basically an email saying, guess what? An account was made for you. If you created it for someone on your team, great. On the other hand, if you are just making it for you, that email has nothing helpful. You can also download a CSV of all the users just created, in this case one, that will have this access key and this secret access key.
[00:09:02] I recommend doing that, mostly cuz you can hit show and see that secret access key. But once you leave that page, if you didn't download the credentials, that's it, you can generate a new key but Amazon is never gonna show you that key again. That is the only time that you are going to see it.
[00:09:22] So if you don't own a CSV, you can peek it open or whatever you want. But again, that is effectively your password, so it probably behooves you to encrypt it or move it to a password manager or something along those lines. Very cool and so will close that up.
[00:09:37] So now, I have these two users that I can use, they both at this point have the same amount of access. I'm going to be using the MobileHub one today but you could also have an administrator one. There are cases again, where you might create additional users depending on your needs.
[00:09:51] Don't think of a user as a human all the time like in some case you are a human, and you are going to need an account. Think of the users also as this app needs such and such permissions. So that you can limit each app to just the amount of access that it needs and no more.
[00:10:07] So if that app gets compromised or those keys get make public by access, cuz who among us hasn't accidentally pushed keys to get hub in a public repo. We've all done it. [LAUGH] This way you can at least limit the damage and just turn off that key cuz it's also problematic like, let's say your app becomes really popular and you have a whole bunch of micro services because it's 2018, why not?
[00:10:26] And then all of a sudden you have to go and change all of those keys. I mean, you should be rotating keys relatively frequently but nobody wants to do it in a rush. Nobody wants to panic, I have to change a thousand different keys, right? So this allows you to limit those things.
[00:10:40] So it's per app. So if one app gets compromised, you can just change the keys for that app. Again, so think about it both in terms of users as well as applications. Cool, so now, we have the users set up. We're gonna be using a whole bunch more Amazon Services today, but this is the kind of raw material that we can integrate from either our terminal or to log in with to see stuff.
[00:11:04] So if you're in your root account now, what I'd like you to do is to sign out,
>> Steve Kinney: And sign back in with the account you just made.
>> Steve Kinney: So If I go to IM,
>> Steve Kinney: Wait for that page to load. You have this URL up here. This is a portal for all your IM sub users.
[00:11:34] So now instead of going to the main page and switching, you can say, okay, actually this account I wanna be the sub user. It's a lot easier just to kind of have this whether you bookmark it or save it somewhere. If this is your very first account, it's a bunch of just random numbers, which is, good luck.
[00:11:49] I mean if you are bookmarking it, whatever, but you can actually hit Customize and in this case you can change it to a different alias. I like this alias, I'm going to keep it but I am gonna take that,
>> Steve Kinney: And I'll go over here and you can see this is the kind of main account and here is the mobile hub user I created.
[00:12:13] I also created that administrator account, either one will work, and we'll sign in with this new sub user. Effectively, once you have created the root user, created the sub user, lock it down with a multi-factor authentication. Do all that stuff, but basically treat it as emergency access only.
[00:12:29] Don't use it as your daily driver. All right, very cool. So now we're back in, and you can see now I'm in this MobileHub account @ the MainAccount. That's normally what you wanna be seeing in this case, cool.