AWS IAM Policy Generator: Politiques IAM, de bucket S3 et d’approbation au moindre privilège — en JSON ou Terraform.

Une politique IAM est un document JSON qui indique quelles actions sont autorisées ou refusées sur quelles ressources, éventuellement sous conditions. Une politique basée sur l'identité est attachée à un utilisateur, un groupe ou un rôle et accorde ses autorisations à cette identité : elle n'a donc pas d'élément Principal. Une politique basée sur les ressources est attachée à la ressource elle-même — un compartiment S3, une file SQS, une clé KMS — et doit nommer le Principal auquel elle s'applique. Quand les deux s'appliquent à une requête dans le même compte, AWS les combine, et un Deny explicite dans l'une ou l'autre l'emporte toujours.

L'élément Principal. Une politique IAM est attachée à un utilisateur, un groupe ou un rôle : le principal est implicite et l'élément n'est pas autorisé. Une politique de compartiment est attachée au compartiment : chaque instruction doit donc dire à qui elle s'applique — un autre compte, l'ARN d'un rôle, un service comme cloudfront.amazonaws.com ou "*" pour tout le monde. Le générateur l'impose dans les deux sens : il exige un Principal en mode compartiment, le refuse en mode identité, et avertit quand une instruction de compartiment accorde Principal "*" sans Condition.

N'accordez que les actions que la charge de travail appelle réellement, et uniquement sur les ressources qu'elle touche : des actions précises plutôt que s3:* ou *, de vrais ARN dans Resource plutôt que "*". Ajoutez des conditions là où elles restreignent davantage l'accès, par exemple aws:SourceVpce, aws:PrincipalOrgID ou une balise de ressource. Faites ensuite vérifier le résultat par AWS : IAM Access Analyzer valide une politique au regard des bonnes pratiques AWS et peut générer une politique à partir des actions qu'un rôle a réellement utilisées, d'après son historique CloudTrail. Le générateur signale les actions génériques, Resource "*" sur les actions d'écriture et de gestion des autorisations, et Allow avec NotAction.

Une politique gérée par le client compte au plus 6 144 caractères. Les politiques en ligne sont limitées par identité, en cumulant toutes les politiques en ligne qui y sont attachées : 2 048 caractères pour un utilisateur, 10 240 pour un rôle et 5 120 pour un groupe. IAM ne compte pas les espaces blancs dans ces limites, c'est pourquoi la jauge de taille mesure le JSON minifié. Une politique de compartiment S3 a sa propre limite de 20 Ko, et aucune de ces limites de caractères ne peut être relevée par une demande de quota.

L'onglet Terraform écrit les mêmes instructions sous forme de bloc data "aws_iam_policy_document", que Terraform convertit en JSON au moment du plan. Référencez son attribut json partout où une politique est attendue : policy = data.aws_iam_policy_document.example.json dans une aws_iam_policy pour une politique gérée, dans une aws_iam_role_policy pour une politique en ligne de rôle, ou dans une aws_s3_bucket_policy pour une politique de compartiment. Si vous préférez garder le JSON brut, jsonencode() ou un heredoc conviennent aussi, mais la source de données garde la politique en HCL, où les diffs restent lisibles.

De l'AWS Service Reference, les fichiers JSON lisibles par machine qu'AWS publie pour chaque service avec ses actions, types de ressources et clés de condition. La page indique la date de récupération des données, et la liste couvre 12 services courants : S3, EC2, Lambda, DynamoDB, IAM, CloudWatch Logs, SQS, SNS, KMS, STS, Secrets Manager et ECR. Chaque action porte son niveau d'accès — Read, List, Write, Permissions management ou Tagging — et les types de ressources auxquels elle peut être restreinte, ce qui alimente les modèles d'ARN et les avertissements. Pour tout autre service, la liste de référence est la Service Authorization Reference de la documentation AWS.

Une politique d'approbation est la politique basée sur les ressources attachée à un rôle IAM qui indique qui peut l'assumer ; les politiques d'autorisation du rôle disent ensuite ce que ce principal peut faire une fois le rôle assumé. Pour GitHub Actions avec OIDC, la politique d'approbation autorise sts:AssumeRoleWithWebIdentity pour le principal fédéré token.actions.githubusercontent.com, avec des conditions qui exigent que la revendication aud soit égale à sts.amazonaws.com et que la revendication sub corresponde à votre dépôt, par exemple repo:my-org/my-repo:ref:refs/heads/main — ou, pour les dépôts créés après le 15 juillet 2026, la forme immuable repo:my-org@<owner-id>/my-repo@<repo-id>:ref:refs/heads/main. Sans la condition sur sub, n'importe quel dépôt GitHub pourrait assumer le rôle. La politique d'approbation d'un rôle est limitée par défaut à 2 048 caractères, ajustable jusqu'à 8 192.

Non. Le générateur s'exécute à 100 % côté client : le catalogue d'actions est livré avec la page et chaque politique est construite dans l'onglet de votre navigateur. Rien n'est envoyé à un serveur, il n'y a ni compte ni inscription, et le lien de partage encode votre politique dans le fragment de l'URL, que les navigateurs n'envoient jamais à un serveur.