1 00:00:06,666 --> 00:00:08,215 - So now let's take a look at another 2 00:00:08,215 --> 00:00:10,024 really important and powerful 3 00:00:10,024 --> 00:00:12,691 feature within AWS called roles. 4 00:00:14,827 --> 00:00:17,345 Roles could be thought of as an 5 00:00:17,345 --> 00:00:19,348 alternate form of authentication. 6 00:00:19,348 --> 00:00:22,538 They provide us with what we call temporary credentials. 7 00:00:22,538 --> 00:00:25,661 Now, let's first start with what not to do. 8 00:00:25,661 --> 00:00:28,016 When we have a credential such as a 9 00:00:28,016 --> 00:00:30,799 username and password, we have 10 00:00:30,799 --> 00:00:33,943 access keys that we'll talk about later on. 11 00:00:33,943 --> 00:00:38,067 What we don't wanna do is embed those within our code, 12 00:00:38,067 --> 00:00:39,795 because if they're in our code and 13 00:00:39,795 --> 00:00:41,983 we go and publish our code to a repo, 14 00:00:41,983 --> 00:00:44,349 it's possible for other people to find them. 15 00:00:44,349 --> 00:00:46,633 It's possible for other people to use them 16 00:00:46,633 --> 00:00:48,577 in ways that they weren't intended. 17 00:00:48,577 --> 00:00:51,568 So we don't want to embed our keys in the code. 18 00:00:51,568 --> 00:00:53,130 Even from a logistical standpoint, 19 00:00:53,130 --> 00:00:57,956 a good practice is to rotate our credentials regularly. 20 00:00:57,956 --> 00:01:00,681 Changing passwords, changing access keys. 21 00:01:00,681 --> 00:01:02,864 And by doing that, it means that we 22 00:01:02,864 --> 00:01:04,525 have to go and update code. 23 00:01:04,525 --> 00:01:06,033 If we embed them within the code, 24 00:01:06,033 --> 00:01:07,927 or in environment variables, now it 25 00:01:07,927 --> 00:01:11,386 adds an extra step that we have to take care of. 26 00:01:11,386 --> 00:01:14,134 So, we don't wanna do that. 27 00:01:14,134 --> 00:01:18,213 We also don't want to share credentials with other people. 28 00:01:18,213 --> 00:01:19,902 And I've seen customers do this, 29 00:01:19,902 --> 00:01:23,002 and it causes a lot of problems downstream. 30 00:01:23,002 --> 00:01:25,053 If you're having multiple people use one 31 00:01:25,053 --> 00:01:27,638 set of credentials and then they change 32 00:01:27,638 --> 00:01:30,109 a password or whatever, it just 33 00:01:30,109 --> 00:01:32,536 causes a lot of downstream effects. 34 00:01:32,536 --> 00:01:35,869 So what we want is a way to authenticate 35 00:01:38,836 --> 00:01:41,428 and authorize a user, but without having 36 00:01:41,428 --> 00:01:44,469 to give them, or without having to embed 37 00:01:44,469 --> 00:01:47,332 or share some long term credentials. 38 00:01:47,332 --> 00:01:49,841 So the answer to that is using roles. 39 00:01:49,841 --> 00:01:52,933 Roles can be used in a number of different ways. 40 00:01:52,933 --> 00:01:56,180 We can attach a role to an EC2 instance, 41 00:01:56,180 --> 00:01:58,401 or a virtual machine, and have that 42 00:01:58,401 --> 00:02:01,176 machine authenticate via that role. 43 00:02:01,176 --> 00:02:03,725 That way, we don't have to embed credentials. 44 00:02:03,725 --> 00:02:06,360 We can have other AWS services 45 00:02:06,360 --> 00:02:09,159 leverage roles on our behalf. 46 00:02:09,159 --> 00:02:11,992 We could have a user assume a role 47 00:02:13,177 --> 00:02:15,391 so that their normal day to day 48 00:02:15,391 --> 00:02:17,202 is done with their account, but if 49 00:02:17,202 --> 00:02:19,690 they wanna do something special, or 50 00:02:19,690 --> 00:02:22,055 switch over in to another account, then 51 00:02:22,055 --> 00:02:25,409 perhaps they would use a role to do that. 52 00:02:25,409 --> 00:02:28,226 You can also use roles to authenticate 53 00:02:28,226 --> 00:02:30,976 for third party accounts as well. 54 00:02:32,143 --> 00:02:35,058 So let's take a look at an EC2 role example. 55 00:02:35,058 --> 00:02:37,902 In this example, let's start with an EC2 56 00:02:37,902 --> 00:02:40,167 instance, or a virtual machine. 57 00:02:40,167 --> 00:02:42,858 Now again, we don't want to embed credentials, 58 00:02:42,858 --> 00:02:45,971 any kind of long term credentials, in this machine. 59 00:02:45,971 --> 00:02:48,874 We don't want to embed it in to environment variables. 60 00:02:48,874 --> 00:02:50,631 We don't want it in our code. 61 00:02:50,631 --> 00:02:52,205 So what we're going to do at 62 00:02:52,205 --> 00:02:54,805 the time we create this machine, 63 00:02:54,805 --> 00:02:57,722 we're going to attach a role to it. 64 00:02:59,420 --> 00:03:02,111 And we're going to give the role the 65 00:03:02,111 --> 00:03:05,390 permissions that this machine needs to access. 66 00:03:05,390 --> 00:03:07,743 Such as, in this particular example, 67 00:03:07,743 --> 00:03:10,091 perhaps this EC2 instance needs to 68 00:03:10,091 --> 00:03:12,808 communicate, upload and/or download 69 00:03:12,808 --> 00:03:16,930 files and objects to the Amazon simple storage service. 70 00:03:16,930 --> 00:03:18,581 So the way that the role works is that 71 00:03:18,581 --> 00:03:22,748 using either the AWS, CLI tools or leveraging the SDK, 72 00:03:24,805 --> 00:03:27,490 If our application is leveraging the SDK, 73 00:03:27,490 --> 00:03:30,267 then either one of these will automatically 74 00:03:30,267 --> 00:03:34,348 detect that this machine has this role attached. 75 00:03:34,348 --> 00:03:36,519 It will then, behind the scenes, 76 00:03:36,519 --> 00:03:38,995 completely automated, done for us. 77 00:03:38,995 --> 00:03:42,526 We don't have to worry about how all this works. 78 00:03:42,526 --> 00:03:44,696 It's just done for us. 79 00:03:44,696 --> 00:03:47,316 The CLI of the SDK will go to the 80 00:03:47,316 --> 00:03:50,322 AWS security token service and request 81 00:03:50,322 --> 00:03:53,970 temporary credentials based on that role. 82 00:03:53,970 --> 00:03:56,180 The AWS Security Token Service will 83 00:03:56,180 --> 00:03:58,528 deliver those temporary credentials. 84 00:03:58,528 --> 00:04:01,874 The CLI and/or the SDK will then 85 00:04:01,874 --> 00:04:03,894 apply those credentials, and then 86 00:04:03,894 --> 00:04:06,579 use them in order to authenticate against 87 00:04:06,579 --> 00:04:08,719 whatever service that we're trying to reach. 88 00:04:08,719 --> 00:04:10,969 In this example, Amazon S3. 89 00:04:12,662 --> 00:04:16,398 The CLI and the SDK will also automatically 90 00:04:16,398 --> 00:04:18,563 renew those credentials when they expire. 91 00:04:18,563 --> 00:04:21,142 So again, temporary credentials, in this case 92 00:04:21,142 --> 00:04:22,744 using a role, these credentials 93 00:04:22,744 --> 00:04:25,171 generally live for about 15 minutes. 94 00:04:25,171 --> 00:04:27,350 In other cases, we can control that and 95 00:04:27,350 --> 00:04:29,662 push that time out to a longer period, 96 00:04:29,662 --> 00:04:32,815 but in most cases, they will default to 15 minutes. 97 00:04:32,815 --> 00:04:35,289 And then, of course, these tools will 98 00:04:35,289 --> 00:04:37,915 cache those credentials, and once they expire, 99 00:04:37,915 --> 00:04:40,502 they will automatically renew them for us. 100 00:04:40,502 --> 00:04:43,034 And so leveraging roles in this way 101 00:04:43,034 --> 00:04:45,972 is a really powerful and really flexible feature 102 00:04:45,972 --> 00:04:49,555 that enables a very high degree of security 103 00:04:50,890 --> 00:04:55,363 without us having to embed keys and credentials 104 00:04:55,363 --> 00:04:58,326 into our code or environment variables.