aws iamInspect users, roles and policies, and debug access
aws iam manages who can do what in an AWS account: users, roles, groups, policies and access keys. Most of the time you use it read-only, to answer 'which policies does this role have?', 'what does this policy allow?' and 'why is this call denied?', plus key rotation and policy simulation.
aws iam list-users|get-role|list-attached-role-policies|get-policy-version|simulate-principal-policy|list-access-keys|... [OPTIONS]You've just been given access to an account and want to see your identity and the human and machine users in it.
aws iamIAM is global: no region, one endpoint (iam.amazonaws.com) for the whole account.
IAM stores principals (users, roles) and JSON policies, and every AWS API request is checked against them by the service you call. A request starts as an implicit deny. An explicit Deny in any applicable policy wins immediately. Within an AWS Organization, SCPs (and RCPs for resources) must allow the action. Then an Allow must come from an identity-based policy on the principal or, for services that support them, a resource-based policy such as a bucket policy. If the principal has a permissions boundary, or the session was created with a session policy, those must allow it too. Roles are assumed through STS (sts:AssumeRole), which checks the role's trust policy and returns temporary credentials. IAM changes are eventually consistent, so a new permission can take a few seconds to apply. Read-only commands like get-role and list-attached-role-policies show the inputs; simulate-principal-policy evaluates identity policies for you.
Every request starts denied; an explicit Deny anywhere wins, and an Allow must survive every policy layer that applies.
The service gathers every policy that applies: the caller's identity policies, the resource's policy, SCPs and RCPs, boundaries and session policies. With nothing else, the answer is an implicit deny.
sts get-caller-identityWhich user or role am I right now?list-users / list-rolesPrincipals in the account (use --query to trim)list-attached-role-policiesManaged policies on a role (--role-name); list-role-policies for inline onesget-policy-versionThe JSON document of a managed policy (--policy-arn, --version-id)get-role --role-name RRole details, including its trust policy (who may assume it)simulate-principal-policyTest whether actions would be allowed for a principal*-access-key(s)list-, create-, update- and delete-access-key: rotate long-lived keysattach-role-policyAttach a managed policy to a role (detach-role-policy removes it)decode-authorization-messageaws sts ...: decode the encoded reason in a denialAttaching AdministratorAccess to 'fix' an AccessDeniedTurns a missing permission into full account control for that principal, and hides what the app actually needs.
Read the error's action and resource, and grant exactly that (e.g. s3:PutObject on arn:aws:s3:::bucket/invoices/*)"Resource": "arn:aws:s3:::kunal-artifacts" for s3:GetObjectObject actions apply to object ARNs; the bucket ARN alone matches nothing for GetObject.
arn:aws:s3:::kunal-artifacts/* for objects, the bucket ARN for s3:ListBucketLong-lived access keys for CI and serversKeys leak through logs, repos and laptops and stay valid until someone notices.
Roles: instance profiles, ECS task roles, EKS Pod Identity, OIDC federation for CIA trust policy with "Principal": {"AWS": "*"}Any AWS account in the world can try to assume the role; only conditions stand in the way.
Name specific accounts, roles or services, and add sts:ExternalId or aws:SourceArn conditionsTry these on a Linux machine of your own. Each task has a hint and a solution.
Write an IAM policy as ~/app/s3-invoices-policy.json that allows only s3:PutObject and s3:GetObject on objects under the invoices/ prefix of bucket devops-artifacts, then validate it is proper JSON with jq.
With jq, list the actions allowed by that file, one per line.
Show who is allowed to assume the role shop-api-task.
Test whether the role shop-api-task may call ec2:TerminateInstances, without terminating anything.
aws iamInspect users, roles and policies, and debug access
aws iam manages who can do what in an AWS account: users, roles, groups, policies and access keys. Most of the time you use it read-only, to answer 'which policies does this role have?', 'what does this policy allow?' and 'why is this call denied?', plus key rotation and policy simulation.
aws iam list-users|get-role|list-attached-role-policies|get-policy-version|simulate-principal-policy|list-access-keys|... [OPTIONS]You've just been given access to an account and want to see your identity and the human and machine users in it.
aws iamIAM is global: no region, one endpoint (iam.amazonaws.com) for the whole account.
IAM stores principals (users, roles) and JSON policies, and every AWS API request is checked against them by the service you call. A request starts as an implicit deny. An explicit Deny in any applicable policy wins immediately. Within an AWS Organization, SCPs (and RCPs for resources) must allow the action. Then an Allow must come from an identity-based policy on the principal or, for services that support them, a resource-based policy such as a bucket policy. If the principal has a permissions boundary, or the session was created with a session policy, those must allow it too. Roles are assumed through STS (sts:AssumeRole), which checks the role's trust policy and returns temporary credentials. IAM changes are eventually consistent, so a new permission can take a few seconds to apply. Read-only commands like get-role and list-attached-role-policies show the inputs; simulate-principal-policy evaluates identity policies for you.
Every request starts denied; an explicit Deny anywhere wins, and an Allow must survive every policy layer that applies.
The service gathers every policy that applies: the caller's identity policies, the resource's policy, SCPs and RCPs, boundaries and session policies. With nothing else, the answer is an implicit deny.
sts get-caller-identityWhich user or role am I right now?list-users / list-rolesPrincipals in the account (use --query to trim)list-attached-role-policiesManaged policies on a role (--role-name); list-role-policies for inline onesget-policy-versionThe JSON document of a managed policy (--policy-arn, --version-id)get-role --role-name RRole details, including its trust policy (who may assume it)simulate-principal-policyTest whether actions would be allowed for a principal*-access-key(s)list-, create-, update- and delete-access-key: rotate long-lived keysattach-role-policyAttach a managed policy to a role (detach-role-policy removes it)decode-authorization-messageaws sts ...: decode the encoded reason in a denialAttaching AdministratorAccess to 'fix' an AccessDeniedTurns a missing permission into full account control for that principal, and hides what the app actually needs.
Read the error's action and resource, and grant exactly that (e.g. s3:PutObject on arn:aws:s3:::bucket/invoices/*)"Resource": "arn:aws:s3:::kunal-artifacts" for s3:GetObjectObject actions apply to object ARNs; the bucket ARN alone matches nothing for GetObject.
arn:aws:s3:::kunal-artifacts/* for objects, the bucket ARN for s3:ListBucketLong-lived access keys for CI and serversKeys leak through logs, repos and laptops and stay valid until someone notices.
Roles: instance profiles, ECS task roles, EKS Pod Identity, OIDC federation for CIA trust policy with "Principal": {"AWS": "*"}Any AWS account in the world can try to assume the role; only conditions stand in the way.
Name specific accounts, roles or services, and add sts:ExternalId or aws:SourceArn conditionsTry these on a Linux machine of your own. Each task has a hint and a solution.
Write an IAM policy as ~/app/s3-invoices-policy.json that allows only s3:PutObject and s3:GetObject on objects under the invoices/ prefix of bucket devops-artifacts, then validate it is proper JSON with jq.
With jq, list the actions allowed by that file, one per line.
Show who is allowed to assume the role shop-api-task.
Test whether the role shop-api-task may call ec2:TerminateInstances, without terminating anything.