Une politique IAM accorde à un rôle kms:Decrypt sur une clé AWS KMS, pourtant l'appel est refusé. Pourquoi ?
Réponse courte
Parce qu'une key policy KMS, contrairement à la plupart des politiques de ressources AWS, ne donne pas automatiquement de permission au compte ni à ses identités. Les allow IAM ne fonctionnent que si la key policy contient une déclaration (celle par défaut utilise le principal racine du compte) qui active les politiques IAM. Sans elle, les politiques IAM qui autorisent l'accès sont sans effet, alors que celles qui le refusent s'appliquent toujours. Vérifiez d'abord la key policy, pas seulement le rôle.
Beaucoup d'ingénieurs AWS apprennent que les politiques d'identité IAM suffisent pour atteindre une ressource. KMS est l'exception classique, et elle tombe en entretien cloud car elle casse ce modèle mental.
Le mécanisme
AWS documente que, contrairement aux autres politiques de ressources AWS, une key policy KMS ne donne pas automatiquement de permission au compte ni à ses identités. La key policy par défaut contient donc une déclaration pour le principal du compte (arn:aws:iam::<account-id>:root) avec kms:*. Cette déclaration n'accorde pas l'accès à tous les principaux ; elle permet au compte d'utiliser des politiques IAM pour déléguer les permissions. AWS précise que sans elle, les politiques IAM qui autorisent l'accès à la clé sont sans effet, alors que celles qui le refusent fonctionnent toujours.
Pourquoi c'est important
- Un rôle avec un parfait allow IAM
kms:Decryptéchoue si la key policy n'a pas cette déclaration d'activation ou a été réécrite. - Une key policy nommant un seul utilisateur risque de rendre la clé ingérable si cet utilisateur est supprimé ; la déclaration du principal du compte réduit ce risque.
- Ordre de débogage : key policy, puis politiques IAM, puis deny explicites.
Pourquoi les distracteurs échouent
Une politique d'approbation contrôle qui peut assumer un rôle, pas ce que le rôle peut faire sur une clé. KMS respecte bien les politiques IAM une fois activées. Les deny l'emportent sur les allow, mais rien ici n'évoque un deny.
Ce que veulent les recruteurs
Savoir que KMS évalue d'abord la key policy et qu'IAM ne fonctionne que si la key policy lui délègue.
Questions de suivi probables
- Que fait réellement la déclaration par défaut de la key policy pour le principal racine du compte ?
- Pourquoi une key policy ne nommant qu'un seul utilisateur nuit-elle à la gérabilité ?
- Comment les grants KMS s'articulent-ils avec les key policies et les politiques IAM ?