Eine IAM-Richtlinie gibt einer Rolle kms:Decrypt auf einem AWS-KMS-Schlüssel, doch der Aufruf wird abgelehnt. Warum?
Kurzantwort
Weil eine KMS-Key-Policy im Gegensatz zu den meisten AWS-Ressourcenrichtlinien dem Konto und seinen Identitäten nicht automatisch Rechte einräumt. IAM-Allows greifen nur, wenn die Key Policy eine Anweisung enthält (die Standardanweisung nutzt den Root-Principal des Kontos), die IAM-Richtlinien aktiviert. Ohne sie sind IAM-Richtlinien, die Zugriff erlauben, wirkungslos, während IAM-Richtlinien mit Deny weiterhin gelten. Prüfen Sie zuerst die Key Policy, nicht nur die Rolle.
Viele AWS-Ingenieure lernen, dass IAM-Identitätsrichtlinien für den Zugriff auf eine Ressource genügen. KMS ist die klassische Ausnahme und taucht in Cloud-Interviews auf, weil sie dieses Denkmodell bricht.
Der Mechanismus
AWS dokumentiert, dass eine KMS-Key-Policy im Unterschied zu anderen AWS-Ressourcenrichtlinien dem Konto oder seinen Identitäten nicht automatisch Rechte gibt. Die Standard-Key-Policy enthält deshalb eine Anweisung für den Konto-Principal (arn:aws:iam::<account-id>:root) mit kms:*. Diese Anweisung gewährt nicht jedem Principal Zugriff, sondern erlaubt dem Konto, die Berechtigungen per IAM-Richtlinien zu delegieren. Laut AWS sind IAM-Richtlinien, die Zugriff auf den Schlüssel erlauben, ohne sie wirkungslos, IAM-Richtlinien mit Deny wirken dagegen weiter.
Warum das wichtig ist
- Eine Rolle mit perfektem IAM-Allow für
kms:Decryptscheitert, wenn die Key Policy diese aktivierende Anweisung nicht enthält oder umgeschrieben wurde. - Eine Key Policy, die nur einen Benutzer nennt, kann den Schlüssel unverwaltbar machen, wenn dieser Benutzer gelöscht wird; die Anweisung für den Konto-Principal mindert das Risiko.
- Debugging-Reihenfolge: Key Policy, dann IAM-Richtlinien, dann explizite Denies.
Warum die Distraktoren scheitern
Eine Vertrauensrichtlinie steuert, wer eine Rolle annehmen darf, nicht was die Rolle mit einem Schlüssel tun darf. KMS beachtet IAM-Richtlinien, sobald sie aktiviert sind. Denies schlagen Allows, doch nichts hier deutet auf ein Deny hin.
Was Interviewer hören wollen
Die Erkenntnis, dass KMS zuerst die Key Policy prüft und IAM nur funktioniert, wenn die Key Policy an IAM delegiert.
Wahrscheinliche Anschlussfragen
- Was bewirkt die Standardanweisung der Key Policy für den Root-Principal des Kontos tatsächlich?
- Warum gefährdet eine Key Policy, die nur einen Benutzer nennt, die Verwaltbarkeit?
- Wie passen KMS-Grants zu Key Policies und IAM-Richtlinien?