1 00:00:06,860 --> 00:00:09,846 - So here let's discuss permissions and policies 2 00:00:09,846 --> 00:00:14,013 within the AWS Identity and Access Management Service. 3 00:00:15,114 --> 00:00:19,222 So we've talked about how we allow our users to authenticate 4 00:00:19,222 --> 00:00:22,816 and authorize against the AWS API. 5 00:00:22,816 --> 00:00:24,876 It's one thing to have a user account, 6 00:00:24,876 --> 00:00:26,936 but that user account by default does 7 00:00:26,936 --> 00:00:29,672 not allow your user to do anything. 8 00:00:29,672 --> 00:00:33,155 In order for our users to be able to actually do their job 9 00:00:33,155 --> 00:00:36,128 and create resources within Amazon Web Services, 10 00:00:36,128 --> 00:00:38,479 we need to grant them permissions. 11 00:00:38,479 --> 00:00:40,802 We have to have an explicit allow 12 00:00:40,802 --> 00:00:42,969 somewhere within their account in order 13 00:00:42,969 --> 00:00:44,710 for them to be able to do anything, 14 00:00:44,710 --> 00:00:47,516 and we do that by way of policies. 15 00:00:47,516 --> 00:00:51,225 Policies are just a simple JSON text. 16 00:00:51,225 --> 00:00:53,840 JSON being JavaScript Object Notation 17 00:00:53,840 --> 00:00:56,787 that we'll talk about later on. 18 00:00:56,787 --> 00:00:59,040 Now we have two different types of policies. 19 00:00:59,040 --> 00:01:01,435 We have what we call manage policies, 20 00:01:01,435 --> 00:01:04,895 which are top level first class objects that can be 21 00:01:04,895 --> 00:01:09,068 directly created and managed apart from other resources. 22 00:01:09,068 --> 00:01:13,174 And you can see that we have both an AWS managed, 23 00:01:13,174 --> 00:01:15,698 meaning that these are policies that are created 24 00:01:15,698 --> 00:01:17,808 and managed by Amazon Web Services, 25 00:01:17,808 --> 00:01:20,226 and then we have customer managed policies. 26 00:01:20,226 --> 00:01:23,410 These are policies that we create and manage on our own. 27 00:01:23,410 --> 00:01:27,039 And so it's common for customers to have their own library 28 00:01:27,039 --> 00:01:29,604 of policies to apply to different 29 00:01:29,604 --> 00:01:33,220 types of users or different groups of users. 30 00:01:33,220 --> 00:01:35,899 And then of course we can have the other type of policy 31 00:01:35,899 --> 00:01:39,031 would be what we call an inline policy. 32 00:01:39,031 --> 00:01:42,279 The inline policy would be where you would put 33 00:01:42,279 --> 00:01:45,796 that policy directly onto a user's account 34 00:01:45,796 --> 00:01:49,452 rather than referencing a managed policy. 35 00:01:49,452 --> 00:01:52,452 Now we have a couple of ways that we can create policies. 36 00:01:52,452 --> 00:01:54,047 We can either use a generator, 37 00:01:54,047 --> 00:01:57,640 which is a simple UI tool that Amazon Web Services gives us 38 00:01:57,640 --> 00:02:01,379 that allows us to choose the service type of actions, 39 00:02:01,379 --> 00:02:04,560 and it will write the JSON policy for us. 40 00:02:04,560 --> 00:02:06,184 We could also just handwrite it 41 00:02:06,184 --> 00:02:08,720 if we want to as well or copy and paste. 42 00:02:08,720 --> 00:02:10,447 Now it's important to understand 43 00:02:10,447 --> 00:02:13,291 the evaluation logic of policies. 44 00:02:13,291 --> 00:02:16,971 They all start with a default implicit deny, 45 00:02:16,971 --> 00:02:19,879 so again, you can't do anything 46 00:02:19,879 --> 00:02:23,193 unless you have an explicit allow. 47 00:02:23,193 --> 00:02:24,766 So the policy evaluation logic 48 00:02:24,766 --> 00:02:27,791 first starts with that implicit deny. 49 00:02:27,791 --> 00:02:32,029 Then it actually looks for an explicit deny. 50 00:02:32,029 --> 00:02:34,157 That's important because generally 51 00:02:34,157 --> 00:02:37,956 you use the explicit denies, and we'll talk about this more 52 00:02:37,956 --> 00:02:40,123 later on, but you would use an explicit deny 53 00:02:40,123 --> 00:02:41,931 to create perhaps what you could 54 00:02:41,931 --> 00:02:44,231 call some safety rails around things. 55 00:02:44,231 --> 00:02:48,262 So with an explicit deny, it can never be overridden. 56 00:02:48,262 --> 00:02:51,795 If you say that a user is not allowed to do something, 57 00:02:51,795 --> 00:02:55,942 then no matter where else they might be allowed, 58 00:02:55,942 --> 00:02:59,149 the explicit deny will always win. 59 00:02:59,149 --> 00:03:00,971 That's the great security layer 60 00:03:00,971 --> 00:03:03,918 that we have access to within policies. 61 00:03:03,918 --> 00:03:07,493 And then of course if it doesn't find an explicit deny, 62 00:03:07,493 --> 00:03:11,246 it will then look for an explicit allow. 63 00:03:11,246 --> 00:03:15,038 So remember that they start with an implicit deny, 64 00:03:15,038 --> 00:03:17,559 and they look for that explicit deny, 65 00:03:17,559 --> 00:03:20,584 which overrides everything, and then, 66 00:03:20,584 --> 00:03:22,962 in order for a user to be able to do anything, 67 00:03:22,962 --> 00:03:27,426 they have to have somewhere an explicit allow. 68 00:03:27,426 --> 00:03:30,516 So before we look at an example policy, 69 00:03:30,516 --> 00:03:32,573 I wanna talk about one other thing 70 00:03:32,573 --> 00:03:35,006 that's really important to understand. 71 00:03:35,006 --> 00:03:39,259 This is very, very key thing in order to understand 72 00:03:39,259 --> 00:03:43,141 security in Amazon, in order to understand writing policies, 73 00:03:43,141 --> 00:03:46,072 and it's called the Amazon Resource Name, 74 00:03:46,072 --> 00:03:50,942 and Amazon Resource Name is a way of uniquely identifying 75 00:03:50,942 --> 00:03:54,836 a particular resource across all of Amazon. 76 00:03:54,836 --> 00:03:58,296 When you imagine that Amazon web services has 77 00:03:58,296 --> 00:04:02,463 over one million paying customers across 14 regions, 78 00:04:03,658 --> 00:04:07,620 38 availability zones, across the entire globe, 79 00:04:07,620 --> 00:04:10,431 there are lots and lots and lots of resources. 80 00:04:10,431 --> 00:04:13,563 Some customers, just one customer may be running 81 00:04:13,563 --> 00:04:15,766 thousands of virtual machines. 82 00:04:15,766 --> 00:04:20,562 They may have dozens of databases, so one customer 83 00:04:20,562 --> 00:04:23,690 might have millions and millions, perhaps even billions 84 00:04:23,690 --> 00:04:28,283 of objects stored within Amazon simple storage service. 85 00:04:28,283 --> 00:04:32,036 It's important to be able to uniquely identify 86 00:04:32,036 --> 00:04:36,711 every single resource within all of Amazon web services, 87 00:04:36,711 --> 00:04:39,934 and we can do that with an Amazon Resource Name. 88 00:04:39,934 --> 00:04:42,220 So you'll notice here that the Amazon Resource Name 89 00:04:42,220 --> 00:04:44,080 follows a particular pattern. 90 00:04:44,080 --> 00:04:46,163 They all start with arn:. 91 00:04:47,224 --> 00:04:51,391 These different parts of the ARN are separated by colons. 92 00:04:52,236 --> 00:04:55,986 So you can see that it will be arn:partition, 93 00:04:56,820 --> 00:04:59,489 the partition being the 94 00:04:59,489 --> 00:05:02,948 high level organization of Amazon Web Services. 95 00:05:02,948 --> 00:05:06,373 Most of the partitions will be named AWS. 96 00:05:06,373 --> 00:05:08,486 If you're operating out of the China region, 97 00:05:08,486 --> 00:05:10,493 one other example is the partition 98 00:05:10,493 --> 00:05:13,826 in that particular case might be AWS-CN, 99 00:05:15,417 --> 00:05:19,036 but for the most part, they will all be AWS. 100 00:05:19,036 --> 00:05:21,507 And then of course comes the name of the service, 101 00:05:21,507 --> 00:05:25,163 the region that we're operating in, such as US West Two 102 00:05:25,163 --> 00:05:29,330 or US East One, the account ID, the resource type, 103 00:05:30,778 --> 00:05:32,770 what kind of resource we're dealing with, 104 00:05:32,770 --> 00:05:37,710 whether it's an s3 bucket, an EC2 virtual machine, or so on, 105 00:05:37,710 --> 00:05:40,404 and then of course the actual name of the resource. 106 00:05:40,404 --> 00:05:43,293 Some resources are separated by a slash. 107 00:05:43,293 --> 00:05:44,905 Sometimes it's a colon. 108 00:05:44,905 --> 00:05:48,164 It's always best to just to go back to the documentation. 109 00:05:48,164 --> 00:05:52,116 I've been using Amazon Web Services for seven years now, 110 00:05:52,116 --> 00:05:54,927 and I constantly go back to the documentation. 111 00:05:54,927 --> 00:05:56,723 These details are too much to remember. 112 00:05:56,723 --> 00:06:01,202 So make the documentation your best friend in these cases. 113 00:06:01,202 --> 00:06:03,843 So just a couple of examples of ARNs. 114 00:06:03,843 --> 00:06:07,948 If we wanted to uniquely identify one user 115 00:06:07,948 --> 00:06:10,100 out of the millions of users that 116 00:06:10,100 --> 00:06:14,267 exist within Amazon web services, this might be our ARN. 117 00:06:15,338 --> 00:06:17,240 You'll see here that it follows that pattern. 118 00:06:17,240 --> 00:06:20,691 Arn:aws: the name of the service, iam being 119 00:06:20,691 --> 00:06:22,620 the service here, and you'll notice 120 00:06:22,620 --> 00:06:25,120 that the region is left blank. 121 00:06:26,553 --> 00:06:30,344 You'll see here that for global services like iam, 122 00:06:30,344 --> 00:06:32,589 the region is not necessary because 123 00:06:32,589 --> 00:06:34,848 it doesn't matter what region. 124 00:06:34,848 --> 00:06:36,868 And then of course we have the account ID, 125 00:06:36,868 --> 00:06:38,943 and as we'll talk about later, 126 00:06:38,943 --> 00:06:42,086 it's very possible and it's very common 127 00:06:42,086 --> 00:06:44,686 and in fact it's suggested, recommended, best practice 128 00:06:44,686 --> 00:06:48,357 to leverage multiple accounts for your environment, 129 00:06:48,357 --> 00:06:49,693 and we'll talk about that later, 130 00:06:49,693 --> 00:06:52,995 but here we have the account ID. 131 00:06:52,995 --> 00:06:54,395 And then of course what we're saying, 132 00:06:54,395 --> 00:06:56,851 the resource type in this case is a user, 133 00:06:56,851 --> 00:07:01,246 not a group, not a role, not anything else but a user. 134 00:07:01,246 --> 00:07:02,926 And then of course the name of that 135 00:07:02,926 --> 00:07:05,759 user in this example being bsmith. 136 00:07:06,871 --> 00:07:10,559 Another example of an ARN is in the case of 137 00:07:10,559 --> 00:07:12,857 here the example is for Amazon Simple 138 00:07:12,857 --> 00:07:16,595 Storage Service, otherwise known as s3. 139 00:07:16,595 --> 00:07:20,919 It's arn:aws:s3, and you can see here in this example, 140 00:07:20,919 --> 00:07:25,824 that the region and the account number are both left blank, 141 00:07:25,824 --> 00:07:29,609 and that's because the name of the bucket 142 00:07:29,609 --> 00:07:33,122 is itself globally unique, and because of that, 143 00:07:33,122 --> 00:07:37,057 we don't need the region or the account ID. 144 00:07:37,057 --> 00:07:39,892 And the last example, all of them are filled in, 145 00:07:39,892 --> 00:07:43,302 the name of the service, the region, the account ID. 146 00:07:43,302 --> 00:07:46,090 In this particular case we are talking about 147 00:07:46,090 --> 00:07:49,418 the Amazon relational database service, 148 00:07:49,418 --> 00:07:52,599 and we are targeting a very specific database 149 00:07:52,599 --> 00:07:57,025 within a particular account within a particular region. 150 00:07:57,025 --> 00:07:59,349 So again, these are the Amazon Resource Names 151 00:07:59,349 --> 00:08:02,044 and a very important thing to understand 152 00:08:02,044 --> 00:08:05,407 when we get into writing policies. 153 00:08:05,407 --> 00:08:08,549 So let's take a look at this example policy. 154 00:08:08,549 --> 00:08:10,388 Now again, as we have talked about, 155 00:08:10,388 --> 00:08:14,150 policies are written in JSON, JavaScript Object Notation. 156 00:08:14,150 --> 00:08:17,053 It's just a simple collection of t value pairs. 157 00:08:17,053 --> 00:08:19,195 Here one of the first things that we need 158 00:08:19,195 --> 00:08:21,187 within our policy is the version, 159 00:08:21,187 --> 00:08:24,013 and we have our key over here called version. 160 00:08:24,013 --> 00:08:25,677 It's quoted, and then the value 161 00:08:25,677 --> 00:08:28,677 separated by a colon, also quoted. 162 00:08:28,677 --> 00:08:30,601 Now the version in this case is not 163 00:08:30,601 --> 00:08:34,095 a semantic version like 1.1 or 2.4. 164 00:08:34,095 --> 00:08:38,031 It's the date at which this policy was last published, 165 00:08:38,031 --> 00:08:42,345 and we can find those versions within the AWS documentation. 166 00:08:42,345 --> 00:08:45,611 The next thing that we need in our policy is a collection 167 00:08:45,611 --> 00:08:47,114 of statements, and you can see that 168 00:08:47,114 --> 00:08:50,403 the square bracket denotes a list or an array. 169 00:08:50,403 --> 00:08:54,327 In this case, we only have one, but it's still a collection. 170 00:08:54,327 --> 00:08:57,191 Now here what we're saying is that we're allowing 171 00:08:57,191 --> 00:09:00,493 this user to perform these two actions. 172 00:09:00,493 --> 00:09:03,662 We can see that actions are prefixed 173 00:09:03,662 --> 00:09:06,096 by the name of the service, in this case, 174 00:09:06,096 --> 00:09:09,080 Amazon Simple Storage Service or s3 175 00:09:09,080 --> 00:09:12,103 is prefixed here to these two actions. 176 00:09:12,103 --> 00:09:16,117 So it's like a name space for those particular actions, 177 00:09:16,117 --> 00:09:18,574 and we're saying that we're going to allow this user 178 00:09:18,574 --> 00:09:21,907 or group of users to download and upload 179 00:09:23,249 --> 00:09:27,226 to this particular resource, and in this example, 180 00:09:27,226 --> 00:09:31,795 as we've talked about, this resource using an ARN, 181 00:09:31,795 --> 00:09:35,950 we're specifying that they're allowed to perform 182 00:09:35,950 --> 00:09:38,927 these actions anywhere within the bucket, 183 00:09:38,927 --> 00:09:41,885 so you'll notice that the bucket would be 184 00:09:41,885 --> 00:09:46,710 mybucket, but the /* is yet another thing. 185 00:09:46,710 --> 00:09:50,370 The /* indicates everything within the bucket. 186 00:09:50,370 --> 00:09:52,203 So again the bucket is one resource. 187 00:09:52,203 --> 00:09:54,033 Objects within the bucket are another. 188 00:09:54,033 --> 00:09:55,781 We'll talk more about how the simple 189 00:09:55,781 --> 00:09:59,187 storage service works later on. 190 00:09:59,187 --> 00:10:02,049 So as we've talked about, 191 00:10:02,049 --> 00:10:06,251 the evaluation logic, it starts with the implicit deny. 192 00:10:06,251 --> 00:10:08,837 It will first look for an explicit deny 193 00:10:08,837 --> 00:10:11,824 and then look for an explicit allow. 194 00:10:11,824 --> 00:10:15,485 So it's also important to note that 195 00:10:15,485 --> 00:10:18,600 users or groups of users can have multiple policies, 196 00:10:18,600 --> 00:10:22,431 and each policy can have multiple statements, 197 00:10:22,431 --> 00:10:27,268 so it would be possible that a user or group of users 198 00:10:27,268 --> 00:10:30,581 somewhere within their policies has a deny 199 00:10:30,581 --> 00:10:32,823 that would override this allow. 200 00:10:32,823 --> 00:10:34,622 It doesn't matter in what order. 201 00:10:34,622 --> 00:10:38,360 The evaluation would first look for a deny, 202 00:10:38,360 --> 00:10:40,225 and then only if it didn't find one 203 00:10:40,225 --> 00:10:43,270 would this allow actually take effect. 204 00:10:43,270 --> 00:10:47,071 So again, this is an example, just one example of a policy 205 00:10:47,071 --> 00:10:51,238 within AWS Identity and Access Management Service. 206 00:10:52,911 --> 00:10:56,224 So ultimately what we can see based on that last example 207 00:10:56,224 --> 00:10:57,714 that policies are essentially 208 00:10:57,714 --> 00:11:00,261 just collections of statements. 209 00:11:00,261 --> 00:11:02,827 It is possible for a user or group of users 210 00:11:02,827 --> 00:11:05,483 to have multiple policies attached. 211 00:11:05,483 --> 00:11:08,784 The statements simply specify, in the case of resource 212 00:11:08,784 --> 00:11:11,924 space policies as we'll talk about more later on, 213 00:11:11,924 --> 00:11:14,991 we specify the who, otherwise the who is already 214 00:11:14,991 --> 00:11:18,330 implicit depending on who the policy is attached to. 215 00:11:18,330 --> 00:11:20,878 We specify actions, the things 216 00:11:20,878 --> 00:11:23,361 that that user is allowed to do. 217 00:11:23,361 --> 00:11:28,224 We specify resources, the actual Amazon Web Services 218 00:11:28,224 --> 00:11:31,892 resources that our users are allowed to do things with. 219 00:11:31,892 --> 00:11:33,395 And then of course, we also have 220 00:11:33,395 --> 00:11:35,843 the ability to specify conditions. 221 00:11:35,843 --> 00:11:38,850 Just a few examples of the possibilities 222 00:11:38,850 --> 00:11:42,615 would be perhaps we want to limit the time of day. 223 00:11:42,615 --> 00:11:44,847 Perhaps we would want to say these users are allowed 224 00:11:44,847 --> 00:11:48,351 to do certain things only during working hours. 225 00:11:48,351 --> 00:11:51,347 Perhaps we want to limit them from a specific IP address, 226 00:11:51,347 --> 00:11:53,601 such as our corporate static IP. 227 00:11:53,601 --> 00:11:56,915 Perhaps we want to say that a group of users 228 00:11:56,915 --> 00:11:59,267 is only allowed to do something, if that resource, 229 00:11:59,267 --> 00:12:01,524 such as a virtual machine or a database, 230 00:12:01,524 --> 00:12:04,006 is tagged in a particular way. 231 00:12:04,006 --> 00:12:07,295 So with permissions via policies 232 00:12:07,295 --> 00:12:10,359 we have very, very fine grain control 233 00:12:10,359 --> 00:12:13,587 over who can do what to what resources 234 00:12:13,587 --> 00:12:17,504 throughout our Amazon Web Services environment.