iam
npx machina-cli add skill itsmostafa/aws-agent-skills/iam --openclawAWS IAM
AWS Identity and Access Management (IAM) enables secure access control to AWS services and resources. IAM is foundational to AWS security—every AWS API call is authenticated and authorized through IAM.
Table of Contents
Core Concepts
Principals
Entities that can make requests to AWS: IAM users, roles, federated users, and applications.
Policies
JSON documents defining permissions. Types:
- Identity-based: Attached to users, groups, or roles
- Resource-based: Attached to resources (S3 buckets, SQS queues)
- Permission boundaries: Maximum permissions an identity can have
- Service control policies (SCPs): Organization-wide limits
Roles
Identities with permissions that can be assumed by trusted entities. No permanent credentials—uses temporary security tokens.
Trust Relationships
Define which principals can assume a role. Configured via the role's trust policy.
Common Patterns
Create a Service Role for Lambda
AWS CLI:
# Create the trust policy
cat > trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "lambda.amazonaws.com" },
"Action": "sts:AssumeRole"
}
]
}
EOF
# Create the role
aws iam create-role \
--role-name MyLambdaRole \
--assume-role-policy-document file://trust-policy.json
# Attach a managed policy
aws iam attach-role-policy \
--role-name MyLambdaRole \
--policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
boto3:
import boto3
import json
iam = boto3.client('iam')
trust_policy = {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {"Service": "lambda.amazonaws.com"},
"Action": "sts:AssumeRole"
}
]
}
# Create role
iam.create_role(
RoleName='MyLambdaRole',
AssumeRolePolicyDocument=json.dumps(trust_policy)
)
# Attach managed policy
iam.attach_role_policy(
RoleName='MyLambdaRole',
PolicyArn='arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole'
)
Create Custom Policy with Least Privilege
cat > policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:PutItem",
"dynamodb:Query"
],
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/MyTable"
}
]
}
EOF
aws iam create-policy \
--policy-name MyDynamoDBPolicy \
--policy-document file://policy.json
Cross-Account Role Assumption
# In Account B (trusted account), create role with trust for Account A
cat > cross-account-trust.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111111111111:root" },
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": { "sts:ExternalId": "unique-external-id" }
}
}
]
}
EOF
# From Account A, assume the role
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CrossAccountRole \
--role-session-name MySession \
--external-id unique-external-id
CLI Reference
Essential Commands
| Command | Description |
|---|---|
aws iam create-role | Create a new IAM role |
aws iam create-policy | Create a customer managed policy |
aws iam attach-role-policy | Attach a managed policy to a role |
aws iam put-role-policy | Add an inline policy to a role |
aws iam get-role | Get role details |
aws iam list-roles | List all roles |
aws iam simulate-principal-policy | Test policy permissions |
aws sts assume-role | Assume a role and get temporary credentials |
aws sts get-caller-identity | Get current identity |
Useful Flags
--query: Filter output with JMESPath--output table: Human-readable output--no-cli-pager: Disable pager for scripting
Best Practices
Security
- Never use root account for daily tasks
- Enable MFA for all human users
- Use roles instead of long-term access keys
- Apply least privilege — grant only required permissions
- Use conditions to restrict access by IP, time, or MFA
- Rotate credentials regularly
- Use permission boundaries for delegated administration
Policy Design
- Start with AWS managed policies, customize as needed
- Use policy variables (
${aws:username}) for dynamic policies - Prefer explicit denies for sensitive actions
- Group related permissions logically
Monitoring
- Enable CloudTrail for API auditing
- Use IAM Access Analyzer to identify overly permissive policies
- Review credential reports regularly
- Set up alerts for root account usage
Troubleshooting
Access Denied Errors
Symptom: AccessDeniedException or UnauthorizedAccess
Debug steps:
- Verify identity:
aws sts get-caller-identity - Check attached policies:
aws iam list-attached-role-policies --role-name MyRole - Simulate the action:
aws iam simulate-principal-policy \ --policy-source-arn arn:aws:iam::123456789012:role/MyRole \ --action-names dynamodb:GetItem \ --resource-arns arn:aws:dynamodb:us-east-1:123456789012:table/MyTable - Check for explicit denies in SCPs or permission boundaries
- Verify resource-based policies allow the principal
Role Cannot Be Assumed
Symptom: AccessDenied when calling AssumeRole
Causes:
- Trust policy doesn't include the calling principal
- Missing
sts:AssumeRolepermission on the caller - ExternalId mismatch (for cross-account roles)
- Session duration exceeds maximum
Fix: Review and update the role's trust relationship.
Policy Size Limits
- Managed policy: 6,144 characters
- Inline policy: 2,048 characters (user), 10,240 characters (role/group)
- Trust policy: 2,048 characters
Solution: Use multiple policies, reference resources by prefix/wildcard, or use tags-based access control.
References
Source
git clone https://github.com/itsmostafa/aws-agent-skills/blob/main/skills/iam/SKILL.mdView on GitHub Overview
IAM enables secure access control for AWS services and resources. IAM is foundational to AWS security because every API call is authenticated and authorized through IAM. Proper IAM configuration helps protect resources and enables auditable access control.
How This Skill Works
IAM uses identities such as users and roles and policy documents to grant permissions. Roles rely on trust relationships to allow trusted entities to assume them, and policies can be identity based, resource based, permission boundaries, or service control policies. The system enforces permissions on every AWS API call.
When to Use It
- When creating IAM policies for precise permissions
- When configuring cross-account access using trust relationships
- When setting up service roles for AWS services like Lambda
- When troubleshooting permission errors or access denials
- When managing access control across users, roles, and resources
Quick Start
- Step 1: Create a trust policy for a service role (for example Lambda) and save as trust-policy.json
- Step 2: Create the role via the CLI using the trust policy and then attach a managed policy
- Step 3: Optionally attach a least-privilege custom policy for your resources
Best Practices
- Define least privilege in each policy by listing only needed actions and resources
- Use service roles for AWS service integration and avoid long lived credentials
- Attach managed policies where possible and create custom policies for specific needs
- Configure strict trust relationships and use external IDs for cross-account access
- Regularly review IAM identities and monitor permissions with Access Advisor
Example Use Cases
- Create a Lambda service role with a trust policy for lambda.amazonaws.com and attach AWSLambdaBasicExecutionRole
- Create a DynamoDB policy with GetItem, PutItem, and Query for a specific table and create a policy named MyDynamoDBPolicy
- Cross-Account Role Assumption: set up trust in the trusted account and assume the role from the other account using an external ID
- CLI example: aws iam create-role followed by aws iam attach-role-policy to grant permissions
- Boto3 example: create a role with an AssumeRolePolicyDocument and attach a managed policy