IAM and Security

S3 ACL

S3 Access Control Lists (ACL) can be thought of as a specialisation of a resource and policy, and it came up in the exam for me. You don’t need to spend too long on this, but try and understand when to use it and how to use it over and above a normal IAM policy.

More importantly, this is an extension of the concept of when you’d use a resource based policy over an identity-based one. If you are really interested, there is good article here that is less dry.

Temporary Access Credentials

This came up in the exam for me, so is worth understanding. Most importantly is the fundamental difference between this and ‘normal’ credentials:

  • Normal credentials ‘stay’ with the user, whereas temporary credentials are requested on demand.
  • When signing a request, you also need to provide a session token when using temp credentials

With this is mind, I’d have a read of the overview page and try and find answers to the following:

What is the use case for using the AssumeRole action on the STS endpoint?

What is a gotcha with a request that has been authenticated successfully, has the correct permission but stops working?

Describe the workflow of using the AssumeRole action endpoint to assume a role. What params come back in an Assume role response?

What are the parameters needed to assume a role, in other words when you call the STS endpoint with the AssumeRole action.

What actually determines the permissions that are assigned from assuming a role?

If I get back a 403 trying to assume a role, how can I get further info? What is a caveat to the above techniques?

How can we use roles to add extra security? Name 2 ways.

Service Linked Roles

Service Linked Roles go hand in hand with temporary credentials and go with the very important concept of least privilege. It’s a type of role that is linked directly to a service and defines everything needed, and no more.

It’s enough for you to find the answers to the following:

What are service–linked roles defined as, and used for?

What defines the lifecycle of the service linked role, i.e how the role is created and deleted?

By default, only the given service can assume the role, but what is a gotcha around the permissions associated with the role?

Which policies do the composite permissions of a linked role span? How do they differ?

What is the makeup of a policy that allows a user to create a service–linked role for a specific AWS service? Assume an RDS instance.


Conclusion

We’ve got through a lot again this week, but this grounding is important for you to understand the patterns of AWS, not just to remember trivia here and there.

I hope this was helpful to you. If you have any feedback, questions, queries about this (or any) article, please feel free to contact me.

Next week we’ll be looking at Dynamo DB.