Lambda supporte les politiques IAM complètes, et une seule API efface tous les triggers

25 août 2026. AWS ouvre les politiques IAM complètes aux fonctions Lambda, dans toutes les régions commerciales et sans surcoût. Trois nouvelles actions apparaissent — PutResourcePolicy, GetResourcePolicy et DeleteResourcePolicy — sur un chemin d’API inédit, /2026-07-09/resource-policy/, tandis que l’ancien chemin AddPermission reste sur /2015-03-31/. La promesse est réelle : un document JSON complet, des clés de condition IAM complètes et des Deny explicites. Mais l’annonce passe sous silence un détail qui change la donne pour la sécurité : un seul appel PutResourcePolicy écrase l’intégralité de la politique, y compris tous les triggers.

Ce qui change réellement

Depuis 2015, la politique de ressources d’une fonction Lambda ne se construisait qu’instruction par instruction, via AddPermission. Ce chemin n’acceptait que trois clés de condition — aws:SourceArn, aws:SourceAccount et aws:PrincipalOrgID — et interdisait tout Deny explicite. Impossible de restreindre par IP source, par tag de principal, ni d’autoriser plusieurs services en une seule déclaration. Pour une équipe qui gère des fonctions multi-comptes, chaque nouveau service autorisé à invoquer une fonction exigeait un appel d’API de plus, éparpillé entre les comptes.

Le nouveau chemin accepte un document JSON complet. On peut désormais écrire des Deny, utiliser toute la gamme des clés de condition globales IAM, et accorder l’accès à plusieurs services dans une seule déclaration au lieu de plusieurs. C’est un rattrapage : les compartiments S3, les files SQS ou les sujets SNS disposaient déjà de politiques de ressources complètes depuis des années. Lambda était l’exception, contrainte par un héritage de 2015. La documentation est claire sur la direction à prendre : AWS recommande de « définir des politiques JSON complètes » pour ajouter des permissions de ressources.

Le piège : PutResourcePolicy remplace tout

Le danger opérationnel est là, noir sur blanc dans le guide du développeur : put-resource-policy remplace toute politique existante, et si la fonction possédait déjà des permissions posées via add-permission, il les écrase. Or personne n’écrit ses permissions de déclencheur à la main. Chaque ressource AWS::Lambda::Permission d’une pile CloudFormation, chaque source d’événement câblée à la console, chaque notification S3 ou cible EventBridge ajoute une instruction via AddPermission. Un seul PutResourcePolicy lancé par une équipe plateforme sur une fonction dont les triggers ont été provisionnés par trois piles différentes les supprime tous en un appel. Le code et la configuration ne changent pas : les triggers cessent simplement d’être autorisés.

La direction inverse se comporte différemment : add-permission appelé après put-resource-policy ajoute une instruction au document existant au lieu de l’écraser. Une pile CloudFormation exécutée après votre déploiement JSON répare donc sa propre instruction ; une pile exécutée avant ne le fait pas. La dérive n’apparaît qu’au prochain déploiement, pas au moment du dégât.

Trois permissions pour une seule API

L’autre surprise est arithmétique. Pour utiliser l’opération qu’AWS recommande pour la gestion au moindre privilège, une identité doit cumuler trois permissions IAM : lambda:PutResourcePolicy, lambda:AddPermission et lambda:RemovePermission. Un rôle qui ne détient que lambda:PutResourcePolicy reçoit un AccessDenied. Un rôle doté des trois peut aussi appeler directement lambda:AddPermission et lambda:RemovePermission, hors de l’éditeur JSON, sur toute fonction atteinte par son bloc Resource.

Conséquence : le rayon d’action côté identité d’un rôle « administrateur de politique » augmente, même si la politique qu’il écrit peut désormais être plus précise. Une équipe qui audite ses changements IAM sur un diff de permissions verra ce diff se dégrader le jour de l’adoption.

Le conflit de documentation sur RevisionId

PutResourcePolicy accepte un paramètre optionnel RevisionId. S’il ne correspond pas, l’appel échoue avec PreconditionFailedException (HTTP 412), afin d’empêcher deux écritures concurrentes de s’écraser. La question est de savoir d’où vient cette valeur — et AWS y répond deux fois, différemment, sur la même page.

Le bloc d’erreur de l’API distingue deux cas : AddPermission et RemovePermission doivent appeler GetPolicy ; « toutes les autres opérations » doivent appeler GetFunction ou GetAlias. PutResourcePolicy tombe dans la seconde catégorie à la lecture littérale. Sauf que GetFunction renvoie le RevisionId de la configuration de la fonction (code et configuration), pas celui de la politique que renvoie GetResourcePolicy. Un ingénieur qui lit ce bloc en pleine interruption, après un 412, suit la consigne, passe un RevisionId du mauvais objet, et sa boucle de retry ne converge jamais.

La règle à encoder dans l’outillage est simple : les RevisionId de politique proviennent de GetResourcePolicy (nouveau chemin) ou GetPolicy (ancien chemin). GetFunction n’est jamais la bonne source pour une précondition de politique.

Le plafond de 20 Ko et le budget de plan de contrôle

Deux limites n’ont pas bougé. La première : le plafond de politique reste à 20 Ko (20 480 caractères exactement), la valeur héritée de l’ancien chemin. Une politique de ressources n’est pas un inventaire IAM complet — elle reste courte par nature — mais les équipes qui y logent des dizaines de déclarations de déclencheurs finiront par buter dessus.

La seconde est plus insidieuse. Les quotas du plan de contrôle Lambda n’ont pas changé : GetFunction à 100 requêtes par seconde, GetPolicy à 15 rps dédiées, et tout le reste mutualisé dans un même seau de 15 rps, non augmentable. GetResourcePolicy et PutResourcePolicy tombent dans ce seau partagé. Le read-modify-write qu’AWS recommande — GetResourcePolicy puis PutResourcePolicy — consomme donc 100 % de plus du budget partagé que l’ancien couple GetPolicy puis AddPermission, et divise par deux le débit effectif (environ 7,5 fonctions par seconde contre 15).

Le bon séquencement, en pratique :

# 1. Lire la politique actuelle ET son RevisionId (jamais via GetFunction)
REVISION_ID=$(aws lambda get-resource-policy \
  --function-name payments-handler \
  --query RevisionId --output text)

# 2. Fusionner, puis réécrire avec le RevisionId fraîchement lu
aws lambda put-resource-policy \
  --function-name payments-handler \
  --policy file://policy-merged.json \
  --revision-id "$REVISION_ID"

À noter : l’annonce vise les régions commerciales. Les expressions régulières des trois nouvelles actions acceptent les ARN des partitions gov, iso et eusc, mais un motif qui correspond à une chaîne ne garantit pas que l’opération soit activée dans ces partitions. Testez dans votre propre partition avant de planifier une migration.

Migrer sans casser : la stratégie par étapes

Le bon déploiement est progressif, jamais un basculement de flotte. Commencez par une fonction pilote sans trigger sensible, écrivez sa politique JSON complète, et vérifiez au diff que les déclarations existantes sont bien reprises. Ne basculez le reste du parc qu’une fois le read-modify-write rodé et les RevisionId correctement gérés.

Côté infrastructure as code, la bascule est un piège à double détente. Les outils CloudFormation, SAM et Terraform supportent le nouveau chemin, mais une pile qui pose encore des AWS::Lambda::Permission réécrira ses déclarations après votre PutResourcePolicy — ou les perdra selon l’ordre d’exécution. La cohérence impose de migrer la pile et la politique ensemble, dans le même déploiement, sinon la dérive s’installe silencieusement.

Enfin, mesurez le coût de plan de contrôle avant de généraliser : si votre pipeline réconcilie des centaines de fonctions, le couple GetResourcePolicy + PutResourcePolicy à 7,5 fonctions par seconde peut étrangler vos déploiements. Séquencez la migration par lots, ou gardez l’ancien chemin pour les fonctions à fort volume de déclencheurs.

Verdict

Si vous êtes une équipe plateforme qui gère des fonctions multi-comptes, adoptez les politiques complètes — elles suppriment enfin la limite des trois clés de condition et autorisent le moindre privilège réel par IP ou par tag. Mais protégez-vous : lisez toujours le RevisionId via GetResourcePolicy, fusionnez avant d’écrire, et auditez d’abord les AWS::Lambda::Permission et triggers existants pour ne pas les écraser au premier appel. Si vous n’avez que quelques fonctions à triggers simples, l’ancien AddPermission reste parfaitement suffisant et évite tout risque d’écrasement.

Références

• AWS Lambda functions now support full IAM resource-based policies — AWS, 25 août 2026
• Lambda resource policy API: 3 permissions, 1 doc conflict — eCorpIT, août 2026
• Viewing resource-based IAM policies in Lambda — AWS Lambda Developer Guide
• AWS Weekly Intelligence #4 — 24-28 August 2026 — Jayanth Katta