Inline policies

Apart from managed policies, AWS also offers inline policies. An inline policy is a policy that is directly embedded in a single user, group, or role. They are not standalone like managed policies and exist solely for the identity to which they are attached. While inline policies can be useful for one-off permission requirements, they can become challenging to manage at scale. If multiple identities require the same permissions, you would have to replicate the inline policy for each identity, leading to redundancy and potential inconsistencies. Hence, the use of inline policies is generally not advised, especially in larger or complex environments.

IAM policy evaluation logic

AWS employs a specific logic when evaluating IAM policies to determine whether a request should be permitted or denied. Understanding this evaluation logic is crucial. It ensures that administrators can predict the outcome of policy changes and troubleshoot access issues effectively. Here is a brief rundown of the process:

• Default deny: All requests are denied by default unless explicitly allowed by a policy.
• Explicit deny: If a policy explicitly denies a particular action, it takes precedence over any allow statement. This ensures that security administrators can enforce stringent restrictions when necessary.
• Explicit allow: If no explicit deny is found, AWS checks for explicit allow statements. If one is found that matches the request, the action is permitted.

As reflected in the following diagram (Figure 3.3), AWS evaluates both identity-based and resource-based policies associated with the request. If any of these policies have an explicit deny, the request is denied. If there is an explicit allow and no corresponding explicit deny, the request is allowed:

Figure 3.3 – Identity-based and resource-based policies evaluation

To illustrate, imagine an IAM user trying to access an S3 bucket. If the user’s attached identity-based policies or the bucket’s resource-based policies have an explicit deny for the user’s action, the request will be denied. If there is no deny but an explicit allow, the user will gain access. If neither is present, the default deny principle will apply, and the user’s request will be denied.

With IAM policies clarified, let’s learn how to craft and oversee them effectively.