Wrap up!

Whenever there is a change to a resource in an AWS account, it comes via one of the AWS APIs. IAM protects these APIs with policies we can attach to different things in the account. Because of this, IAM is the most critical service to secure an AWS account. Everything that touches a resource is subject to it but it’s our responsibility to configure it to only allow what is needed for normal operations and deny everything else.

Recap

IAM follows a well-defined process to decide whether it allows a request or not. First, it constructs the request context with the data from the request itself as well as metadata about the Resource, the Principal, and other sources. We covered this in the Access elements lessons.

Then it moves on to collect all the policies that can be applied to the request. Policies are JSON documents that are attached to identities (users, groups, or roles), resources, sessions, identities as permissions boundary, or accounts. Each of these policy documents defines a set of properties that describe how they influence IAM during the authorization process. Most of them are filters that define which requests the policy applies to. We covered how policies work in the IAM policies chapter.

The last step in the authorization process is the policy evaluation process. This is where IAM considers the matching policies and decides whether to allow or deny the operation in the request. This has multiple steps which we covered in the Evaluation flow lesson.

By understanding the process that governs the access control in AWS, we’ll be able to reason about who can do what in an account and write policies that allow and deny the operations in a controlled and fine-grained manner. And tight access control is the basis of a secure cloud.