Hello welcome back.
So let's now look at when should we use or what are the use cases or what is the recommendation to use.
Object is yells and bucket is yells.
So let's start with object itself.
What are the use cases.
So if you have a bucket owned by a county and an object that was allowed to account B and to allow to
upload it so the object is right here in a bucket.
Owned by a county.
The only way that you can use to grant permissions access to missions to the object now by B is that
the object is yes an object.
Israel is the only way to manage access to objects not owned by the bucket owner.
That's the only way this can happen.
So when can this happen is when the bucket owner authorized another account to upload object to the
bucket.
But still the bucket owner will not own the object.
However remember account a as the bucket owner can do multiple things here can completely deny access
to the object even if the ACL is there the bucket will deny it.
Second is he can delete the object.
Third is it can archive the objects that are not owned by the bucket owner but from and allow object
operation perspective this can only be done by Account B.
Okay so the first use case is the object Israel must be used when there is an object in a bucket.
That permission to that object need to be configured by the object owner which is not the bucket owner
and the second one is when you need to be very granular at the permissions at the object level.
So in this case you need the object itself as well.
Why do you need to use that.
Because bucket policies are limited to 20 kilobytes in size.
Now if it is limited to 20 kilobytes in size you cannot go.
If I have 1000 objects two thousand objects inside here I cannot go object by object policies inside
the bucket policy remember the bucket policy can define the permissions.
The expositions on the bucket level and the object level as well.
So in this case also you can go by the object easier but also you need to remember that object is he
has a limited two hundred granted permissions biracial so one object can have one ACL but there is only
one hundred permissions that or hundred grants as they call it.
So to whom and to do what.
What the operation and what person or entity allowed to do that.
Now.
What about bucket ACL.
We know that there are ACL level buckets as well.
When.
When should we use that.
The only recommended and this is a lobbyist recommended use case for a bucket.
ACL is to grant right permission for the logs to look Delivery Group to right access log object to your
bucket.
So when you want access logs to S3 or anything else to be saved to a bucket then you need to provide
a bucket.
In this case so if you want Amazon S3 to deliver access logs to your bucket you will need to grant right
permission to the bucket on the bucket to the long delivery group you can use bucket an object AC ls
to grant cross account permissions to other accounts but ACL support only a finite set of permissions.
These don't include all Amazon S three permissions.
So as we mentioned before that you can use object sales to grant cross account permissions so you are
in a county and you have an object and this object is owned by account and you want to provide access
to that to account B.
So what you use object is yields same thing for bucket if you want to get grant permissions on the bucket.
Then you use also bucket easy for that for cross account permission it's their limitations.
They can grant basically dried permissions to other NWS accounts.
There are limits to managing permissions using seals.
For example you can grant permissions only to other database account.
You cannot grant permissions to users in your account.
So if you're using AC ls this is only for other accounts not for your account which is so you can use
user policy or bucket policy if you want to define users.
If you want to define access policies and permissions to users in your account in the same account you
can not grant conditional permissions or explicit deny permissions and ACLJ are suitable for specific
scenarios.
Here's an example bucket ACL allows.
So this is on my account.
It allows account B to upload objects to this bucket using ACL.
OK.
Once the object is allowed the bucket Israel cannot control the object once it's loaded because it's
owned by a different account.
Right.
So B owns the object and can do nothing about that.
So in this case account we only can do the AC ls on the object that they have configured so this covers
when to use object is yells bucket is heels and the limitations for the ACL.
And as we mentioned I take away from this picture would be that bucket policies can supplement bucket
seals for what ACL cannot control from a permit promotion perspective because they have a limited set
of operations that they can allow permissions to in the next lecturing are going to cover when to use
bucket or use a policy.
So now we understand when to use object seals and there are scenarios that I must use for object seals
cross account permissions on on the object level and we also understood that ACL can be used at the
object and bucket level to do cross account permissions.
That's fine.
Now what about user and bucket policies and when to use them.
That's what we'll see in the next lecture.
Take a break now and I will see you then.