Instructor: So now let's discuss how authorization 2 2
is working for Amazon S3. 3 3
And that can be quite complicated, 4 4
but this is just general rule 5 5
and then we'll drill down into some use cases. 6 6
So first we look at the user context. 7 7
Is the IAM principal authorized by the parent accounts? 8 8
Does it mean for example, 9 9
that it has the correct IAM policy. 10 10
And if the parent owns the bucket or the object, 11 11
because you should know that you have different level 12 12
of ownerships within buckets 13 13
and we'll talk about those in details as well. 14 14
So if the parent owns the bucket or the object, 15 15
then the bucket policy or the object ACL 16 16
is going to be evaluated. 17 17
And we'll see that ACLs are deprecated 18 18
but still worth mentioning in this lecture. 19 19
Now, if the parent owns the bucket and objects, 20 20
it can grant permission to its IAM principals 21 21
using Identity-Based Policy or Resource-Based Policy. 22 22
We'll have a look at this to see the distinction 23 23
between buckets and objects not owned by the account owner. 24 24
Next we have the bucket context. 25 25
So we're going to evaluate the policies 26 26
of the account that owns the bucket. 27 27
We're going to check for an explicit deny. 28 28
And then we have the object context. 29 29
So we're going to look at the requester. 30 30
Does it have the permissions from the object owner? 31 31
So two cases. 32 32
If the bucket owner is also the object owner, 33 33
then the access is granted using a bucket policy 34 34
and that's the most common use case we've seen so far. 35 35
Or if the bucket owner is not equal to the object owner 36 36
then the access is granted using object owner ACL. 37 37
So to simplify things, because ACLs are quite complicated, 38 38
as you can see the rules are very, very difficult 39 39
to understand, AWS has created a setting 40 40
called Bucket Owner Enforced Setting for Object Ownership. 41 41
That means that the bucket owner 42 42
and the objects are the same. 43 43
And then if you do this, then the ACLs applied to the bucket 44 44
or the objects are not editable anymore 45 45
and they're no longer considered for access, 46 46
which simplifies a lot of the authorization flow. 47 47
Still, I'm gonna show you everything with diagrams 48 48
so you can understand these rules. 49 49
And just remember SCLs are somewhat out of the picture 50 50
so they can be not considered, 51 51
but as a security specialist 52 52
you should still know about them. 53 53
So let's take an example of an IAM user. 54 54
It makes a request. 55 55
So we look at whether or not we are a user or a role. 56 56
Yes, we are a user. 57 57
So we'll look at the user context. 58 58
And we'll look at whether or not the IAM policy 59 59
authorizes us to access the object in Amazon S3. 60 60
If no, well, access denied. 61 61
If yes, then we go into the bucket context. 62 62
Now we'll look at the bucket owner 63 63
and we'll look at if there is an explicit deny. 64 64
If there is, then of course we deny it. 65 65
If not, then we look at the object context, 66 66
and here we look at the authority assigned 67 67
by the object owner. 68 68
And the object owner, 69 69
if it has unauthorized the access, then denied. 70 70
If yes, granted. 71 71
And if we are just not looking at an IAM role or user, 72 72
then we go straight into the bucket context. 73 73
So this is for example, if you have like public access. 74 74
So this is the theory. 75 75
Now let's go into some practice with three accounts. 76 76
Why three? 77 77
Well, in this example, we have a user 78 78
in account one, a bucket in account two, 79 79
and the accounts that owns the object 80 80
inside of the bucket is account three. 81 81
It's a edge use case, but you need to understand it 82 82
to really understand how things work. 83 83
And then we'll go into more simple use cases. 84 84
So here in this case, S3 is going to verify 85 85
that first Jill has the correct permissions 86 86
to perform the requested operation. 87 87
That makes sense. 88 88
Then S3 is going to evaluate the bucket policy 89 89
to determine if the bucket owner 90 90
has explicitly denied Jill access to the objects. 91 91
So if there is no bucket policy that explicitly denies Jill, 92 92
then we move on. 93 93
And then we will evaluate the object ACL 94 94
to determine if Jill has the proper permission 95 95
to access the object. 96 96
And so that means that account three 97 97
should have authorized account one to access the object. 98 98
So in this use case, as you can see, 99 99
we have three different accounts, 100 100
but in the case where the account two 101 101
is also the account three, 102 102
then ACLs are out of the picture. 103 103
And the only thing that can be considered 104 104
is the bucket policy. 105 105
Finally, to understand how authorization works 106 106
in Amazon S3, we must talk about bucket operations 107 107
versus object operations. 108 108
So if we look at the first statement, 109 109
it has an S3 ListBucket, and it turns out 110 110
that the resources it applies to is the bucket named test. 111 111
It's called a bucket level permission. 112 112
That makes sense. 113 113
But then if you look at the second statement, 114 114
then we have GetObject, PutObject, and DeleteObject. 115 115
As you can see, the ARN now has /*. 116 116
So this /* right here means 117 117
that we consider any object within the bucket. 118 118
And so that is object level permission. 119 119
So that makes sense. 120 120
Some APIs are on the bucket 121 121
and some APIs are on the objects. 122 122
And the way to differentiate it is by lengthening the ARN. 123 123
And if you want to apply to all objects, then we'll have /*. 124 124
So we've seen how authorization works in Amazon S3. 125 125
We'll go into more examples over time. 126 126
But you know the basics, 127 127
and I know this is a complicated lecture. 128 128
Don't worry. 129 129
Watch the next ones, and then if you're still curious, 130 130
just watch this one again, and you'll be good to go. 131 131
All right, that's it. 132 132
I hope you liked it and I will see you in the next lecture.