AWS IAM: A closer look

Users and groups

When you open an AWS account, the identity you begin with has access to all AWS services and resources in that account. You use this root account's identity to establish less-privileged users and role-based access in IAM. IAM is a centralized mechanism for creating and managing individual users and their permissions with your AWS account. Every interaction you make with AWS is authenticated.

Users and groups should be used for managing access to resources within your account. When you have an organization that spans multiple AWS accounts, you need to manage access to all the AWS accounts centrally via identity federation because users and groups are not scalable.

An IAM group is a collection of users. Groups allow you to specify permissions for similar types of users. For example, if you have a group named Developers, you can give that group the types of permissions that developers typically need. Create groups reflecting organization roles, it is not technical commonality.

Roles

IAM roles allow you to delegate access to users, applications, or services that normally don't have access to your organization's AWS resources.
You can assume a role to obtain temporary security credentials that you can use to make AWS API calls, just like Suri was added to the Internal Candidate List and able to use the company boat. Consequently, you don't have to share long-term credentials or define permissions for each entity that requires access to a resource.
When you assume a role, it's like putting on a different hat. Each role, or hat, comes with specific access permissions, and assuming each role allows you take on the access permissions of that role.

Roles can be used in the following scenarios:

• An IAM user or role in the same or different AWS account that needs the access that the role provides
• Applications on an Amazon Elastic Compute Cloud (Amazon EC2) instance that need access to AWS resources
• An AWS service that needs to call other services on your behalf or create and manage resources in your account.
• An external user authenticated by an identity provider service that is compatible with SAML 2.0 or OpenID Connect, or a custom-built identity broker

If your organization uses multiple accounts, roles will be a key part of your strategy of centrally managing user's access across multiple accounts.

Types of AWS credentials

A user in AWS consists of a name, a password to sign in to the AWS Management Console, and up to two access keys, which can be used with the API or CLI.

• Username and password: A password policy is a set of rules that define the type of password an IAM user can set. You should define a password policy for all of your IAM users to enforce strong passwords and to require your users to regularly change their passwords. Password requirements are similar to those found in most secure online environments.
• Multi-factor authentication (MFA): This is an additional layer of security for accessing AWS services. With this authentication method, more than one authentication factor is checked before access is granted, which consists of a user name, a password, and the single-use code from the MFA device. AWS CLI also supports MFA.
• User access key: Users need their own access keys to make programmatic calls to AWS using the AWS CLI or the AWS SDKs, or direct HTTPS calls using the APIs for individual AWS services. Access keys are used to digitally sign API calls made to AWS services. Each access key credential consists of an access key ID and a secret key. Each user can have two active access keys, which is useful when you need to rotate the user's access keys or revoke permissions.

IAM request context

These 3 main pieces make up the request context that is authenticated by IAM and authorized accordingly. You can think of the principal, action, and resource as the subject, verb, and object of a sentence, respectively.

• Principal: User, role, external user, or application that sent the request and the policies associated with that principal
• Action: What the principal is attempting to do
• Resource: What the principal is attempting to do AWS resource object upon which the actions or operations are performed

Access through identity-based policies

You manage access in AWS by creating policies and attaching them to IAM identities or AWS resources. An identity-based policy is an object in AWS that, when associated with an IAM identity, defines their permissions. AWS evaluates these policies when a principal entity (IAM user or role) makes a request. Permissions in the policies determine whether the request is allowed or denied. Most policies are stored in AWS as JSON documents.

• AWS managed: AWS manages and creates these types of policies. They can be attached to multiple users, groups, and roles. If you are new to using policies, AWS recommends that you start by using AWS managed policies.
• Customer managed: These are policies that you create and manage in your AWS account. This type of policy provides more precise control than AWS managed policies and can also be attached to multiple users, groups, and roles.
• Inline: Inline policies are embedded directly into a single user, group, or role. In most cases, AWS doesn’t recommend using inline policies. This type of policy is useful if you want to maintain a strict one-to-one relationship between a policy and the principal entity that it's applied to. For example, use this type of policy if you want to be sure that the permissions in a policy are not inadvertently assigned to a principal entity other than the one they're intended for.

IAM identity-based policy

Access in AWS is managed by creating policies and attaching them to IAM identities (users, groups of users, or roles) or AWS resources. A policy is an object in AWS that, when associated with an identity or resource, defines their permissions. AWS evaluates these policies when an IAM principal (user or role) makes a request regardless if it is from the AWS Management Console, the AWS CLI, or the AWS API.

To use a policy to control access in AWS, you must first understand how IAM grants access. When you use the AWS API, the AWS CLI, or the AWS Management Console to take an action, such as creating a role or activating an IAM user access key, you send a request for that action. Using the example policy above, take a look at how IAM evaluates the first statement of this policy.

1. First, IAM checks that the user (the principal) is authenticated (signed in) to perform the specified action on the specified resource.
2. Then, IAM confirms that the user is authorized (has the proper permissions) by checking all the policies attached to your user.
3. During authorization, IAM verifies that the requested actions are allowed by the policies.
4. IAM also checks any policies attached to the resource that the user is trying to access. These policies are known as resource-based policies. If the identity-based policy allows a certain action but the resource-based policy does not, the result will be a deny.
5. AWS authorizes the request only if each part of your request is allowed by the policies. By default, all requests are denied. An explicit allow overrides this default, and an explicit deny overrides any allows. After your request has been authenticated and authorized, AWS approves the actions in your request. Then, those actions can be performed on the related resources within your account.

Policy types

AWS supports six types of policies below. All of these polices are evaluated before a request is either allowed or denied.

1. Identity-based: Also known as IAM policies, identity-based policies are managed and inline policies attached to IAM identities (users, groups to which users belong, or roles). Impacts IAM principal permissions.
2. Resource-based: These are inline policies that are attached to AWS resources. The most common examples of resource-based policies are Amazon S3 bucket policies and IAM role trust policies. Resource-based policies grant permissions to the principal that is specified in the policy; hence, the principal policy element is required. Grants permission to principals or accounts (same or different accounts).

1. Permissions boundaries: A permissions boundary sets the maximum permissions that an identity-based policy can grant to an IAM entity. The entity can perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. Resource-based policies that specify the user or role as the principal are not limited by the permissions boundary. Restricts permissions for the IAM entity attached to it.

1. AWS Organizations SCPs: AWS Organizations is a service for grouping and centrally managing AWS accounts. If you enable all features in an organization, then you can apply SCPs to any or all of your accounts. SCPs specify the maximum permissions for an account, or a group of accounts, called an organizational unit (OU). Restricts permissions for entities in an AWS account, including AWS account root users.

1. ACLs: Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs are supported by Amazon S3 buckets and objects. They are similar to resource-based policies although they are the only policy type that does not use the JSON policy document structure. ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account.

2. Session policies: A session policy is an inline permissions policy that users pass in the session when they assume the role. The permissions for a session are the intersection of the identity-based policies for the IAM entity (user or role) used to create the session and the session policies. Permissions can also come from a resource-based policy. Session policies limit the permissions that the role or user's identity-based policies grant to the session. An upcoming section will cover session policies in more detail. Restricts permissions for assumed roles and federated users.

Guardrails vs. grants
As you noticed from reviewing the different policy types above, some policies are used to restrict permissions while others are used to grant access. Using a combination of different policy types not only improves your overall security posture but also minimizes your blast radius in case an incident occurs

Explicit and implicit denies

A request results in an explicit deny if an applicable policy includes a Deny statement. If policies that apply to a request include an Allow statement and a Deny statement, the Deny statement trumps the Allow statement. The request is explicitly denied.

An implicit denial occurs when there is no applicable Deny statement but also no applicable Allow statement. Because an IAM user, role, or federated user is denied access by default, they must be explicitly allowed to perform an action. Otherwise, they are implicitly denied access.

The flow chart below provides details about how the decision is made as AWS authenticates the principal that makes the request. AWS evaluates the policy types in the following order:

Note that within an account, you need a service control policy AND an IAM policy OR a resource-based policy. Across accounts, you need a service control policy AND an IAM policy AND a resource-based policy.

Key takeaways

• IAM lets you create roles, and doing so allows you to define a set of permissions and then let authenticated users assume them. This feature increases your security posture by granting temporary access to the resources you define.
• You can use IAM to grant your employees and applications access to the AWS Management Console and to AWS service APIs using your existing identity systems.
• IAM is integrated into most AWS services. This integration provides the ability to define access controls from one place in the AWS Management Console that will take effect throughout your AWS environment.
• By default, all requests are implicitly denied (the AWS account root user has full access by default).
• An explicit allow in an identity-based or resource-based policy overrides the default.
• If a permissions boundary, AWS Organizations SCP, or session policy is present, it might override the allow with an implicit deny.
• An explicit deny in any policy overrides any allows.
• If the requested resource has a resource-based policy that allows the requested action, then AWS returns a final decision of allow. If there is no resource-based policy or if the policy does not include an Allow statement, then the evaluation continues.
• If there is a session policy present and it does not allow the requested action, then the request is implicitly denied.