How does the trust relationship policy in IAM roles work?

An IAM role's trust relationship policy, often called a trust policy, is a resource-based policy attached directly to the role that defines who is allowed to assume it. It acts as a gatekeeper, specifying the principals (users, roles, AWS accounts, or AWS services) that can initiate the sts:AssumeRole action.

How It Works

When a principal attempts to assume an IAM role, AWS Security Token Service (STS) evaluates the role's trust policy. This policy must explicitly grant the sts:AssumeRole action to the requesting principal. If the trust policy permits the assumption, STS issues temporary security credentials (access key ID, secret access key, and session token) to the principal. These temporary credentials then allow the principal to perform actions defined by the role's permissions policy, which is separate and dictates what the role can do once assumed. The trust policy is fundamental for cross-account access, granting permissions to AWS services, or enabling federated users.

Policy Structure and Best Practices

Trust policies are defined in JSON. The Principal element specifies the entity allowed to assume the role. This can be an AWS account (e.g., arn:aws:iam::123456789012:root), an IAM user, another IAM role, or an AWS service (e.g., ec2.amazonaws.com). The Action must be sts:AssumeRole.

Conditions can be added for enhanced security. For instance, sts:ExternalId is crucial for cross-account roles to prevent the "confused deputy" problem, ensuring only an intended third party can assume the role. Other common conditions include aws:SourceIp (restricting by IP address) or aws:MultiFactorAuthPresent (requiring MFA).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "my-unique-external-id"
        }
      }
    }
  ]
}

Best practices include applying the principle of least privilege by specifying exact principals, using conditions like sts:ExternalId for cross-account access, and avoiding * in the Principal element unless absolutely necessary for specific AWS service roles.

In the interview, also mention the crucial distinction between the trust policy (who can assume the role) and the permissions policy (what actions the role can perform once assumed).