Gérez AWS Identity and Access Management (IAM) pour les utilisateurs, les rôles, les politiques et les autorisations. Créez des politiques IAM, configurez l'accès inter-comptes, définissez des rôles de service, résolvez les erreurs d'autorisation et appliquez le principe de « privilèges minimaux ».
...Développer toutAWS IAM
AWS Identity and Access Management (IAM) permet un contrôle d'accès sécurisé aux services et ressources AWS. IAM constitue le fondement de la sécurité AWS : chaque appel à l'API AWS est authentifié et autorisé via IAM.
Table des matières
- Concepts fondamentaux
- Modèles courants
- Référence CLI
- Meilleures pratiques
- Dépannage
- Références
Concepts fondamentaux
Entités principales
Entités pouvant effectuer des requêtes auprès d'AWS : utilisateurs d'IAM, rôles, utilisateurs fédérés et applications.
Politiques
Documents JSON définissant les autorisations. Types :
- Basées sur l'identité: associées à des utilisateurs, des groupes ou des rôles
- Basées sur les ressources: associées à des ressources (compartiments S3, files d’attente SQS)
- Limites d’autorisations: autorisations maximales qu’une identité peut détenir
- Politiques de contrôle des services (SCP): limites à l'échelle de l'organisation
Rôles
Identités dotées d’autorisations pouvant être assumées par des entités de confiance. Pas d’identifiants permanents : utilise des jetons de sécurité temporaires.
Relations de confiance
Définissent quels entités peuvent assumer un rôle. Configurées via la politique de confiance du rôle.
Modèles courants
Créer un rôle de service pour Lambda
CLI AWS :
# Créer la politique de confiance
cat > trust-policy.json << 'EOF'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "lambda.amazonaws.com" },
"Action": "sts:AssumeRole"
}
]
}
EOF
# Créer le rôle
aws iam create-role \
--role-name MyLambdaRole \
--assume-role-policy-document file://trust-policy.json
# Associer une politique gérée
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"
}
]
}
# Créer un rôleiam.create_role(
RoleName='MyLambdaRole',
AssumeRolePolicyDocument=json.dumps(trust_policy)
)
# Associer une politique gérée
iam.attach_role_policy(
RoleName='MyLambdaRole',
PolicyArn='arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole'
)
Créer une politique personnalisée avec le principe du moindre privilège
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
Prise en charge d’un rôle inter-comptes
# Dans le compte B (compte de confiance), créez un rôle avec une relation de confiance pour le compte 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
# Depuis le compte A, assumer le rôle
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CrossAccountRole \
--role-session-name MySession \
--external-id unique-external-id
Référence de l'interface CLI
Commandes essentielles
| Commande | Description |
|---|---|
aws iam create-role |
Créer un nouveau rôle d'IAM |
aws iam create-policy |
Créer une politique gérée par le client |
aws iam attach-role-policy |
Associer une politique gérée à un rôle |
aws iam put-role-policy |
Ajouter une politique intégrée à un rôle |
aws iam get-role |
Récupérer les détails d'un rôle |
aws iam list-roles |
Répertorier tous les rôles |
aws iam simulate-principal-policy |
Tester les autorisations de la politique |
aws sts assume-role |
Assumer un rôle et obtenir des informations d’identification temporaires |
aws sts get-caller-identity |
Récupérer l’identité actuelle |
Indicateurs utiles
--query: filtrer la sortie avec JMESPath--output table: sortie lisible par l'utilisateur--no-cli-pager: désactive le paginateur pour les scripts
Bonnes pratiques
Sécurité
- N'utilisez jamais le compte root pour les tâches quotidiennes
- Activez l'authentification multifactorielle (MFA) pour tous les utilisateurs humains
- Utilisez des rôles plutôt que des clés d'accès à long terme
- Appliquez le principe du « privilège minimal » : n'accordez que les autorisations nécessaires
- Utilisez des conditions pour restreindre l'accès par adresse IP, heure ou authentification multifactorielle
- Renouvelez régulièrementles identifiants
- Utiliser des limites d’autorisation pour l’administration déléguée
Conception des politiques
- Commencez par les politiques gérées par AWS, puis personnalisez-les selon vos besoins
- Utilisez des variables de politique (
${aws:username}) pour les politiques dynamiques - Privilégiez les refus explicites pour les actions sensibles
- Regroupez logiquement les autorisations associées
Surveillance
- Activez CloudTrail pour l’audit des API
- Utilisez l'Access Analyzer d'IAM pour identifier les politiques trop permissives
- Consultez régulièrement les rapports sur les identifiants
- Configurer des alertes concernant l’utilisation du compte root
Dépannage
Erreurs « Accès refusé »
Symptôme : AccessDeniedException ou UnauthorizedAccess
Étapes de débogage :
- Vérifier l'identité :
aws sts get-caller-identity - Vérifiez les politiques associées :
aws iam list-attached-role-policies --role-name MyRole - Simuler l'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 - Vérifiez la présence de refus explicites dans les SCP ou les limites d'autorisation
- Vérifiez que les politiques basées sur les ressources autorisent le principal
Impossible d’assumer le rôle
Symptôme : « AccessDenied » lors de l’appel de la fonction ` AssumeRole`
Causes :
- La politique de confiance n'inclut pas l'entité appelante
- Absence de l'autorisation `
sts:AssumeRole` chez l'appelant - Incohérence d’ExternalId (pour les rôles inter-comptes)
- La durée de la session dépasse la limite maximale
Solution : Vérifiez et mettez à jour la relation de confiance du rôle.
Limites de taille des politiques
- Politique gérée : 6 144 caractères
- Politique intégrée : 2 048 caractères (utilisateur), 10 240 caractères (rôle/groupe)
- Politique de confiance : 2 048 caractères
Solution : utilisez plusieurs politiques, référencez les ressources par préfixe ou caractère générique, ou utilisez un contrôle d'accès basé sur des balises.
Références
- IAM Guide de l'utilisateur
- IAM Référence API
- IAM Référence de l'interface en ligne de commande
- Référence des politiques
- boto3 IAM
---
name: iam
description: Manage AWS Identity and Access Management for users, roles, policies, and permissions. Create IAM policies, configure cross-account access, set up service roles, troubleshoot permission errors, and enforce least-privilege security.
---
# AWS 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](#core-concepts)
- [Common Patterns](#common-patterns)
- [CLI Reference](#cli-reference)
- [Best Practices](#best-practices)
- [Troubleshooting](#troubleshooting)
- [References](#references)
## 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:**
```bash
# 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:**
```python
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
```bash
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
```bash
# 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:**
1. Verify identity: `aws sts get-caller-identity`
2. Check attached policies: `aws iam list-attached-role-policies --role-name MyRole`
3. Simulate the action:
```bash
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
```
4. Check for explicit denies in SCPs or permission boundaries
5. 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:AssumeRole` permission 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
- [IAM User Guide](https://docs.aws.amazon.com/IAM/latest/UserGuide/)
- [IAM API Reference](https://docs.aws.amazon.com/IAM/latest/APIReference/)
- [IAM CLI Reference](https://docs.aws.amazon.com/cli/latest/reference/iam/)
- [Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html)
- [boto3 IAM](https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/iam.html)
Installer iam
Téléchargez et décompressez les fichiers de compétences dans votre répertoire .claude/skills/.
Télécharger le ZIPClonez le dépôt et copiez les fichiers de compétence dans votre projet.
git clone https://github.com/itsmostafa/aws-agent-skills/tree/main/skills/iam # Copy SKILL.md to your .claude/skills/ directory
Copier





Maison
