Be A Better Dev: Daniel, this is so timely for me! On my current project, I'm _literally_ in the middle of creating a lambda to trigger off of s3:CreateObject events which then invokes a step function! Love your explanations of AWS concepts, they're super clear and concise. ❤ AWS's IAM docs are hopeless. 😩

@BeABetterDev

2 жыл бұрын

Thanks so much ro pro! Hope this video helps!

Very nicely explained. Thanks for the effort you have put in making such videos.

Super helpful resource thanks!! 😊

Thanks for the tutorial. Really helped me a lot what I wanted to do. 👍

very well explained. thanks

Nicely explained. Thank you!

Very Useful, thank you!

Awesome as always

Thank you! Very clear explanation.

@BeABetterDev

Жыл бұрын

You're very welcome Michael!

Thanks for this video.

@BeABetterDev

2 жыл бұрын

You're very welcome!

Cool! nice tutorial thanks !

@BeABetterDev

2 жыл бұрын

You're very welcome Lina!

Very clearly explained. *****

@BeABetterDev

2 жыл бұрын

Glad it was helpful!

thank you

Tks! from MX.

Thanks for this amazing tutorial. I have a question for you with respect to the cross-account S3 bucket access. If the root user on account B has got access to the S3 bucket sitting on account A then will that make any role of account B access to this bucket (on account A) if the access was given on the role by account B

Thank you for the great video! A question please, is it required to allow both sides (IAM Policy and S3 Bucket policy) in order to access an S3 object or is it that 1 of them is enough?

Do you have a link to that flow chart @8:35? It's too small to read for me.

@BeABetterDev

2 жыл бұрын

Hi BR, here you go: docs.aws.amazon.com/IAM/latest/UserGuide/images/PolicyEvaluationHorizontal111621.png

@BR-lx7py

2 жыл бұрын

@@BeABetterDev Thanks, I bookmarked it :) That is quite complex, no wonder why IAM is a beast.

I have a question, but first, very good. I was never told before that the principal field goes just with S3 policies. On to the question, if we're allowed to act on a bucket, can't we operate on its objects as well? In your example you gave access to both bucket and objects.

@CptSupermrkt

2 жыл бұрын

No, access to the bucket and access to the data ("objects") in the bucket are considered two different things. You might hear these concepts described as "management plane access'" and "data plane access". If you only have access to the bucket, you have access to change settings and attributes on the bucket, but not the data inside it. So you could, for example, change the lifecycle policy on the bucket or the default encryption, but not download objects from the bucket. This distinction helps create user access schemes that properly divide roles and responsibilities. Your local cloud infrastructure team may manage the attributes of the bucket to ensure compliance, but not have access to the data which may be sensitive customer data for example. Conversely, your data scientists may need access to that sensitive customer data for legitimate reasons, but you don't want them screwing with the bucket settings. In his example, yes, he gave permission to both the bucket and bucket objects. This effectively grants true "full access" to the bucket in all facets, including the objects. In a real scenario, this is common for dev/test and environments that don't require the division of permissions.

@renejacques8288

2 жыл бұрын

@@CptSupermrkt Thanks. I'm getting ready to take the AWS developer assoc. exam; any pointers? I purchased some courses on Udemy. I'm not quite sure if they're good prep.

@CptSupermrkt

2 жыл бұрын

@@renejacques8288 I passed all Associates and DevOps Pro using essentially just practice exams. Everyone's learning style is different, but for me, watching courses doesn't work. What I would do is, take a practice exam, then grade my answers in one of three ways: 1) Correct - I got it right, and I actually knew the concepts. 2) Correct - I got it right, but it was either a lucky guess or a 50/50 guess 3) Incorrect For questions that were #2 and #3, then I would deep dive into those particular things, usually by using my personal AWS account to act out the problem myself. I just did like 5 questions a day like this, not much, but consistent: before you know it, you'll have filled in your gaps, and ready for the exam.

@BeABetterDev

2 жыл бұрын

This is really great advice. Thanks for sharing with the viewers.

@harryspooner

Жыл бұрын

@@CptSupermrkt Really well explained with context.

I get a principal error when trying to add a bucket policy which gives access to a bucket from a different amazon account and role on that account. The other person does not want to assume a role I created them in my iam they just want access from their account and role added directly on the bucket policy

Oh Canada! Is there really a “zed” in “reZources”? 😊

@BeABetterDev

2 жыл бұрын

Haha you caught me!

If i give permission to s3 bucket in bucket policy to a user but no in IAM policy, can the user access the s3 bucket?

@jimbean1056

2 жыл бұрын

As long as the user iam role is allowed to make s3 calls, the s3 bucket policy will allow the user in

@fxy2933

Жыл бұрын

NO

Hello. I want to deny GetObject for all users in minio, but it doesn't work. Here is a bucket policy. { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": { "AWS": [ "*" ] }, "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::my-bucket/*" ] } ] } And user has readwrite policy. { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*" ], "Resource": [ "arn:aws:s3:::*" ] } ] }.