AWS Principals

IAM Users

IAM users represent basic users in AWS. This kind of users can authenticate using 4 main methods:

• Username + Password

• Access keys, often used for programmatic and automated interactions with AWS using the API

• SSH keys

• Server Certificates that can be used with the AWS Certificate Manager (ACM) to provision, manage, and deploy certificates

There is a limit of 2 API tokens for each user.

Each IAM user will have a Root user which is the most powerful user in the AWS account but it's not the same thing as the [[AWS Organizations#Management / Root account | Root account]]. Generally it's recommended to use a SCP that deactivates root users of children accounts leaving only a root user for the management account; in case this configuration is too drastic, the root users should only be used just in case there is no other option to recover a lost user account or grant permission over a resource.

Disabling the password (console access) for an IAM user prevents them from signing in to the AWS Management Console using their sign-in credentials.

IAM User Groups

An IAM User Group is a collection of IAM users that allows to specify permissions for multiple users at the same time as the policies attached to a specific group are inherited by users.

• A user group can contain many users, and a user can belong to multiple user groups.

• User groups can't be nested; they can contain only users, not other user groups.

• There is no default user group that automatically includes all users in the AWS account. If you want to have a user group like that, you must create it and assign each new user to it.

• The number and size of IAM resources in an AWS account, such as the number of groups, and the number of groups that a user can be a member of, are limited.

IAM Roles

IAM Roles are IAM identities you can create in your account that has specific permissions: an IAM role is similar to an IAM user, in that it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS.

Roles and users are both AWS identities with permissions policies that determine what the identity can and cannot do in AWS. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

A service role is an IAM role that a service assumes to perform actions on your behalf.

Delegation involves setting up a trust between two accounts: the trusting account, which contains the resource, and the trusted account, which contains the user that needs to access the resource. The trusted and trusting accounts can be any of the following:

• The same account

• Separate accounts that are both under your organization's control

• Two accounts owned by different organizations

To delegate permission to access a resource, you create an IAM role] in the trusting account that has two policies attached. The permissions policy grants the user of the role the needed permissions to carry out the intended tasks on the resource.

The trust policy indicates who can access a role and it's required as a resource-based policy attached to a role in IAM.

Multi-Factor Authentication (MFA)

MFA can be enabled for password authentication and CLI authentication; it can be of three different types:

• Passkeys and security keys

• Virtual authenticator applications

• Hardware TOTP tokens

SCPs can also check for whether MFA is enabled for a user or not.

IAM Boundaries

IAM boundaries can be used to limit the permissions a user or role should have access to. This way, even if a different set of permissions are granted to the user by a different policy the operation will fail if he tries to use them.

A boundary is just a policy attached to a user which indicates the maximum level of permissions the user or role can have. So, even if the user has Administrator access, if the boundary indicates he can only read S· buckets, that's the maximum he can do.

Boundaries, along with SCPs and following the least privilege principle are the ways to control that users doesn't have more permissions than the ones he needs.

IAM Policies

• Identity-based policies – Attach managed and inline policies to IAM identities (users, groups to which users belong, or roles). Identity-based policies grant permissions to an identity.

• Resource-based policies – Attach inline policies to 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. Principals can be in the same account as the resource or in other accounts.

• Permissions boundaries – Use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity.

• Organizations SCPs – Use an AWS Organizations service control policy (SCP) to define the maximum permissions for account members of an organization or organizational unit (OU). SCPs limit permissions that identity-based policies or resource-based policies grant to entities (users or roles) within the account, but do not grant permissions.

• Access control lists (ACLs) – Use ACLs to control which principals in other accounts can access the resource to which the ACL is attached. ACLs 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.

• Session policies – Pass advanced session policies when you use the AWS CLI or AWS API to assume a role or a federated user. Session policies limit the permissions that the role or user's identity-based policies grant to the session. Session policies limit permissions for a created session, but do not grant permissions.

More information here.

IAM Password Policy

The default password policy for IAM users is the following:

• 8 < password length < 128

• Minimum of three of the following mix of characters

  • uppercase

  • lowercase

  • numbers

  • symbols

• Password has to differ from the AWS account name of the email address used to register it.

Identity Providers and Federation

Amazon recommends to require "Human users" to use federation with an identity provider to access AWS resources instead of creating individual IAM users in your AWS account. With an identity provider (IdP), you can manage your user identities outside of AWS and give these external user identities permissions to use AWS resources in your account. With an identity provider (IdP), you can manage your user identities outside of AWS and give these external user identities permissions to use AWS resources in your account.

When a user uses an IdP, they're not required to create a custom sign-in code or manage user identities as the IdP provides that functionality for you: external users can sign into the provider and it's possible to assign specific permissions to those external identities towards specific AWS resources. IdPs are useful and secure because it's not required to distribute long-term security credentials in applications.

IAM federation type	Account type	Access management of..	Supported identity source
Federation with IAM Identity Center	Multiple accounts managed by AWS Organizations	Your workforce’s human users	SAML 2.0 / Managed Active Directory / Identity Center directory
Federation with IAM	Single, standalone account	Human users in short-term, small scale deployments / Machine users	SAML 2.0 / OIDC
Federation with Amazon Cognito identity pools	Any	The users of apps that require IAM authorization to access resources	SAML 2.0 / OIDC / Select OAuth 2.0 social identity providers

It's strongly recommended to manage "human users" in IAM Identity Center

IAM allows you to use separate SAML 2.0 and Open ID Connect (OIDC) IdPs and use federated user attributes for access control. With IAM, you can pass user attributes, such as cost center, title, or locale, from your IdPs to AWS, and implement fine-grained access permissions based on these attributes.

A workload is a collection of resources and code that delivers business value, such as an application or backend process. Your workload can require an IAM identity to make requests to AWS services, applications, operational tools, and components. These identities include machines running in your AWS environments, such as Amazon EC2 instances or AWS Lambda functions.

IAM Identity Center

AWS IAM Identity Center (successor to AWS Single Sign-On) expands the capabilities of AWS Identity and Access Management (IAM) to provide a central place that brings together administration of users and their access to AWS accounts and cloud applications.

The login domain is going to be something like <user_input>.awsapps.com.

To login users, there are 3 identity sources that can be used:

• Identity Center Directory: Regular AWS users

• Active Directory: Supports different connectors

• External Identity Provider: All users and groups come from an external Identity Provider (IdP)