IAM: users, groups, roles and policies, least privilege, federation and IAM Identity Center

Why this matters

Every action on AWS, from opening the console to deleting a database, is checked against one question: who is asking, and are they allowed? Get the answer wrong and the consequences are concrete. A developer's leaked access key can let a stranger run up a bill or copy customer data. An intern with administrator rights can delete production by accident. Five people sharing one login leave no way to tell which of them made a change.

Identity and access management is the part of AWS security that the customer owns completely. AWS runs the service, but every user, every permission and every sign-in rule is the customer's decision. A manager needs the vocabulary to approve access requests sensibly. A salesperson needs to explain how a client's staff will sign in without a new password for every account. A junior engineer needs to know why the right answer for an application is almost never "paste a key into the code". The concepts here are few, but they come up all through the exam.

The lesson

Identity and access management with AWS IAM

Authentication proves who you are. Authorisation decides what you may do once AWS knows who you are. AWS Identity and Access Management (IAM) handles both for an AWS account, and it is offered at no additional charge. Its building blocks are:

• An IAM user is a long-term identity for one person or, less ideally, one application. A user can have a console password for signing in to the AWS Management Console, and access keys for programmatic access through the CLI, SDKs or APIs.
• An IAM group is a collection of users. A policy attached to the group applies to every member, so permissions are managed in one place. Groups hold users, not other groups, and a group is not an identity that signs in.
• An IAM role is an identity with permissions but no long-term credentials of its own: no password and no access keys. A trusted user, AWS service or federated identity assumes the role and receives temporary credentials that expire automatically.
• A policy is a JSON document whose statements allow or deny actions on resources. It takes effect when attached to an identity or a resource.

Policies come in two broad kinds. Identity-based policies attach to a user, group or role and describe what that identity may do. Resource-based policies attach to a resource and name who may act on it; an Amazon S3 bucket policy that lets another AWS account read objects is the standard example.

When a request arrives, IAM evaluates every policy that applies to it together. Everything starts denied by default. An explicit allow grants access, but an explicit deny in any applicable policy always overrides an allow, wherever the allow came from. A group policy has no precedence over a user's own policy; a single deny wins.

Roles are how AWS services get permissions safely. An application on an EC2 instance should use a role attached to the instance, through an instance profile, so it receives temporary credentials that AWS rotates for it. A Lambda function runs with an execution role that grants exactly the actions it needs, such as writing items to a DynamoDB table. Storing access keys in source code, or on a server, creates long-term secrets that can leak through source control or a copied image. Never use the root user's keys for this. The root user, the account's original all-powerful identity, should be protected with MFA, should have no access keys, and should be used only for the few tasks that require it, as lesson 10 explains.

Give each person their own identity. With individual identities, AWS CloudTrail records show which person made each change, and one person's access can be removed without affecting anyone else.

Principle of least privilege

Least privilege means granting each person or workload only the permissions it needs to do its job, and nothing more. It limits the damage from a mistake or a stolen credential: an identity that cannot delete a database cannot delete it by accident or under an attacker's control.

In practice this means starting small and adding, not starting broad and waiting for abuse. It also means reviewing over time. IAM last accessed information shows which services, and for some services which actions, an identity has used and when, so permissions that are never used can be removed with confidence.

Do not confuse least privilege with separation of duties, a related idea that splits a sensitive task between people so that no single person can complete it alone.

AWS IAM Identity Center

AWS IAM Identity Center is the recommended way to give an organisation's workforce access to AWS. It works with AWS Organizations: an employee signs in once and reaches every AWS account, and supported applications, that they have been assigned, with access managed centrally rather than account by account.

The key object is the permission set, a collection of policies that defines a level of access, such as read-only or developer. An administrator assigns a user or group, with a permission set, to an account, and Identity Center creates a matching IAM role in that account. The user's session then uses temporary credentials from that role.

Identity Center can keep users in its own directory, or connect to an existing identity source such as a corporate identity provider or Active Directory.

Keep two neighbours apart. Amazon Cognito handles sign-up and sign-in for the customers of an application, such as users of a mobile app, not staff access to AWS accounts. AWS Directory Service provides managed Microsoft Active Directory; it can be an identity source but is not the single sign-in portal itself.

How AWS checks identity: MFA, IAM Identity Center and cross-account roles

These are the ways people and systems prove who they are on AWS:

• A password plus multi-factor authentication (MFA). MFA adds a second proof, something the user has, such as a code from an authenticator app or a security key. A stolen password alone is then not enough to sign in. MFA proves identity; it does not encrypt anything.
• Sign-in through IAM Identity Center, once, for all assigned accounts.
• Access keys for programmatic calls from the CLI or an SDK.
• Assuming a role, including a cross-account IAM role. Account B creates a role that trusts account A. Auditors in account A assume it and receive temporary credentials limited to what the role allows, say read-only. This is better practice than creating extra IAM users in account B, which adds long-term credentials that must be managed and later removed.

Network rules, storage lifecycle rules and compliance checks are not authentication methods. A security group filters traffic; it never decides who you are.

Users, groups and policies built for least privilege

Putting the pieces together the way AWS recommends:

1. Create an individual identity for each person, preferably through IAM Identity Center; never share one login.
2. Put people with the same job into a group and attach the policy to the group. Forty developers then get the same permissions from one attachment, and one edit changes them all.
3. Choose the right kind of policy:
4. AWS managed policies are created and maintained by AWS. You can attach them, but you cannot edit them. They are a quick start, but often broader than a given job needs.
5. Customer managed policies are written by you, can be edited, and can be attached to many identities. They are the usual tool for tailoring permissions tightly.
6. Inline policies are embedded in a single user, group or role and are deleted with it. They suit a strict one-to-one relationship.
7. Use roles, not stored keys, for applications and services.
8. Review regularly with last accessed information and remove what is unused.

Attaching broad policies such as AdministratorAccess to every new user is the opposite of this approach.

Federation and other kinds of identity management

Identity federation lets people sign in with an identity that lives outside AWS, in an external identity provider (IdP), and receive temporary AWS credentials. No IAM user is created for each person. Corporate IdPs commonly use the SAML 2.0 standard; web and social sign-in commonly use OpenID Connect.

Three patterns are worth recognising:

• Workforce federation: employees use their existing corporate credentials to reach AWS, through IAM Identity Center or through an IAM identity provider and roles.
• Customer identity: an application's own users sign up, or sign in with social accounts, through Amazon Cognito user pools.
• Local IAM users: identities created and stored in IAM itself, with long-term credentials. Still valid, but AWS prefers federation and temporary credentials for people.

When a scenario says "existing corporate credentials" and "no separate IAM users", the answer is federation.