How AWS enforcement code logic evaluates requests to allow or deny access - AWS Identity and Access Management

How AWS enforcement code logic evaluates requests to allow or deny access

The AWS enforcement code decides whether a request sent to AWS should be allowed or denied. AWS evaluates all policies that are applicable to the request context. The following is a summary of the AWS policy evaluation logic.

  • By default, all requests are implicitly denied with the exception of the AWS account root user, which has full access.

  • Requests must be explicitly allowed by a policy or set of policies following the evaluation logic below to be allowed.

  • An explicit deny overrides an explicit allow.

The following flow chart provides details about how the decision is made for both single account and cross-account access.

Evaluation flow chart

  • Deny evaluation – By default, all requests are denied. This is called an implicit deny. The AWS enforcement code evaluates all policies within the account that apply to the request. These include AWS Organizations SCPs and RCPs, resource-based policies, identity-based policies, IAM permissions boundaries, and session policies. In all those policies, the enforcement code looks for a Deny statement that applies to the request. This is called an explicit deny. If the enforcement code finds even one explicit deny that applies, the enforcement code returns a final decision of Deny. If there is no explicit deny, the enforcement code evaluation continues.

  • Organizations RCPs – The enforcement code evaluates AWS Organizations resource control policies (RCPs) that apply to the request. RCPs apply to resources of the account where the RCPs are attached. If the enforcement code does not find any applicable Allow statements in the RCPs, the enforcement code returns a final decision of Deny. Note that an AWS managed policy called RCPFullAWSAccess is automatically created and attached to every entity in your organization including the root, each OU, and AWS account when RCPs are enabled. RCPFullAWSAccess can't be detached, so there will always be an Allow statement. If there is no RCP, or if the RCP allows the requested action, the enforcement code evaluation continues.

  • Organizations SCPs – The enforcement code evaluates AWS Organizations service control policies (SCPs) that apply to the request. SCPs apply to principals of the account where the SCPs are attached. If the enforcement code does not find any applicable Allow statements in the SCPs, the enforcement code returns a final decision of Deny. If there is no SCP, or if the SCP allows the requested action, the enforcement code evaluation continues.

  • Resource-based policies – Within the same account, resource-based policies impact policy evaluation differently depending on the type of principal accessing the resource, and the principal that is allowed in the resource-based policy. Depending on the type of principal, an Allow in a resource-based policy can result in a final decision of Allow, even if an implicit deny in an identity-based policy, permissions boundary, or session policy is present.

    For most resources, you only need an explicit Allow for the principal in either an identity-based policy or a resource-based policy to grant access. IAM role trust policies and KMS key policies are exceptions to this logic, because they must explicitly allow access for principals.

    Resource-based policy logic differs from other policy types if the specified principal is an IAM user, an IAM role, or a session principal. Session principals include IAM role sessions or an IAM federated user session. If a resource-based policy grants permission directly to the IAM user or the session principal that is making the request, then an implicit deny in an identity-based policy, a permissions boundary, or a session policy does not impact the final decision.

    • IAM role – Resource-based policies that grant permissions to an IAM role ARN are limited by an implicit deny in a permissions boundary or session policy. You can specify the role ARN in the Principal element or the aws:PrincipalArn condition key. In both cases, the principal that makes the request is the IAM role session.

      Permissions boundaries and session policies do not limit permissions granted using the aws:PrincipalArn condition key with a wildcard(*) in the Principal element, unless the identity-based policies contain an explicit deny. For more information, see IAM role principals.

      Example role ARN

      arn:aws:iam::111122223333:role/examplerole

    • IAM role session – Within the same account, resource-based policies that grant permissions to an IAM role session ARN grant permissions directly to the assumed role session. Permissions granted directly to a session are not limited by an implicit deny in an identity-based policy, a permissions boundary, or session policy. When you assume a role and make a request, the principal making the request is the IAM role session ARN and not the ARN of the role itself. For more information, see Role session principals.

      Example role session ARN

      arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname

    • IAM user – Within the same account, resource-based policies that grant permissions to an IAM user ARN (that is not a federated user session) are not limited by an implicit deny in an identity-based policy or permissions boundary.

      Example IAM user ARN

      arn:aws:iam::111122223333:user/exampleuser

    • IAM federated user sessions – An IAM federated user session is a session created by calling GetFederationToken. When a federated user makes a request, the principal making the request is the federated user ARN and not the ARN of the IAM user who federated. Within the same account, resource-based policies that grant permissions to a federated user ARN grant permissions directly to the session. Permissions granted directly to a session are not limited by an implicit deny in an identity-based policy, a permissions boundary, or session policy.

      However, if a resource-based policy grants permission to the ARN of the IAM user who federated, then requests made by the federated user during the session are limited by an implicit deny in a permission boundary or session policy.

      Example IAM federated user session ARN

      arn:aws:sts::111122223333:federated-user/exampleuser

  • Identity-based policies – The enforcement code checks the identity-based policies for the principal. For an IAM user, these include user policies and policies from groups to which the user belongs. If there are no identity-based policies or no statements in identity-based policies that allow the requested action, then the request is implicitly denied and the enforcement code returns a final decision of Deny. If any statement in any applicable identity-based policies allows the requested action, the code evaluation continues.

  • IAM permissions boundaries – The enforcement code checks whether the IAM entity that is used by the principal has a permissions boundary. If the policy that is used to set the permissions boundary does not allow the requested action, then the request is implicitly denied. The enforcement code returns a final decision of Deny. If there is no permissions boundary, or if the permissions boundary allows the requested action, the code evaluation continues.

  • Session policies – The enforcement code checks whether the principal is a session principal. Session principals include an IAM role session or an IAM federated user session. If the principal is not a session principal, the enforcement code returns a final decision of Allow.

    For session principals, the enforcement code checks whether a session policy was passed in the request. You can pass a session policy while using the AWS CLI or AWS API to get temporary credentials for a role or an IAM federated user. If you didn't pass a session policy, a default session policy is created and the enforcement code returns a final decision of Allow.

    • If a session policy is present and does not allow the requested action, then the request is implicitly denied. The enforcement code returns a final decision of Deny.

    • The enforcement code checks whether the principal is a role session. If the principal is a role session, then the request is Allowed. Otherwise, the request is implicitly denied and the enforcement code returns a final decision of Deny.

    • If a session policy is present and allows the requested action, then the enforcement code returns a final decision of Allow.