In vielen AWS-Konten darf ein Team über Terraform oder eine CI-Pipeline eigene IAM-Rollen und -Policies anlegen, zum Beispiel um neue Lambda-Funktionen oder EC2-Instanzen mit passenden Rollen auszustatten. Das Problem: Wer iam:CreateRole und iam:AttachRolePolicy darf, kann im Zweifel auch eine Rolle mit AdministratorAccess bauen und sich selbst daran anhängen. Eine Identity-based Policy allein kann diesen Weg nicht zuverlässig versperren, sie beschreibt nur, was erlaubt ist, keine Obergrenze. Genau dafür gibt es Permission Boundaries.

Was eine Permission Boundary tatsächlich tut

Eine Permission Boundary ist selbst eine verwaltete Policy. Sie wird beim Erstellen oder Aktualisieren eines IAM-Users oder einer IAM-Rolle gesetzt und vergibt dabei keine eigenen Rechte. Sie legt nur fest, was die maximal mögliche Berechtigung dieser einen Entität sein kann, unabhängig davon, welche Identity-based Policy ihr heute oder später angehängt wird.

Die effektive Berechtigung einer Entität mit Boundary ist die Schnittmenge aus Identity-based Policy und Permission Boundary, nicht deren Vereinigung. Eine Aktion ist nur erlaubt, wenn sowohl die Identity-based Policy sie zulässt als auch die Boundary sie zulässt. Hängt jemand der Entität nachträglich AdministratorAccess an, ändert das nichts an der Obergrenze: Was die Boundary nicht erlaubt, bleibt verweigert, egal wie großzügig die angehängte Policy ist.

Eine Boundary setzen

Die Boundary wird über den Parameter PermissionsBoundary bei CreateUser beziehungsweise CreateRole gesetzt oder nachträglich über die API-Aktionen iam:PutUserPermissionsBoundary und iam:PutRolePermissionsBoundary geändert. Wer diese beiden Aktionen für eine Entität selbst ausführen darf, kann ihre Boundary austauschen oder entfernen. Genau deshalb braucht eine Boundary-Policy zusätzlich einen Selbstschutz, siehe unten.

Beispiel: Pfad-Prefix plus Selbstschutz

Die folgende Boundary erlaubt einem Deployment-Account, eigene Rollen unterhalb des Pfads /deploy/ zu verwalten, dazu ein festes Set an Arbeitslast-Rechten. Der letzte Block verhindert, dass die Entität ihre eigene Boundary ändert oder entfernt.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowScopedIamManagement",
      "Effect": "Allow",
      "Action": [
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:PutRolePolicy",
        "iam:DeleteRolePolicy",
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy",
        "iam:TagRole",
        "iam:UntagRole",
        "iam:UpdateAssumeRolePolicy"
      ],
      "Resource": "arn:aws:iam::*:role/deploy/*"
    },
    {
      "Sid": "AllowDeploymentWorkload",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "cloudwatch:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyBoundaryEscape",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRolePermissionsBoundary",
        "iam:PutRolePermissionsBoundary",
        "iam:DeleteUserPermissionsBoundary",
        "iam:PutUserPermissionsBoundary"
      ],
      "Resource": "*"
    }
  ]
}

Diese Policy wird der Rolle oder dem User als Permission Boundary zugewiesen, nicht als Identity-based Policy. Die tatsächlichen Rechte entstehen weiterhin aus der normalen Identity-based Policy der Entität, begrenzt auf das, was hier erlaubt ist.

Der Escalation-Pfad, den der letzte Block schließt

Ohne den DenyBoundaryEscape-Block bleibt eine naheliegende Lücke offen. Besitzt die Entität die Aktionen iam:PutRolePermissionsBoundary oder iam:DeleteRolePermissionsBoundary für sich selbst, kann sie die eigene Boundary gegen eine großzügigere Boundary austauschen oder vollständig entfernen. Danach greift nur noch die Identity-based Policy, und die Obergrenze existiert nicht mehr. Das typische Schutzmuster gegen diesen Weg ist deshalb ein expliziter Deny auf genau diese Aktionen innerhalb der Boundary selbst, unabhängig davon, was der Rest der Policy erlaubt.

Abgrenzung zu SCPs und zu Policy as Code

Permission Boundaries wirken nur auf die eine IAM-Entität, der sie zugewiesen sind, nicht organisationsweit über ein Konto oder eine OU. Wo die Obergrenze kontoweit über alle Prinzipale hinweg durchgesetzt wird, auch gegen den Root-User, geht der Beitrag AWS Organizations Service Control Policies: warum AdministratorAccess im Mitgliedskonto trotzdem nichts bringt genauer ein.

Permission Boundaries wirken außerdem zur Laufzeit, direkt in der IAM-Evaluierungslogik von AWS, unabhängig davon, mit welchem Werkzeug die Rolle angelegt wurde. Wie sich Policy-Verstöße schon vor dem terraform apply abfangen lassen, beschreibt der Beitrag Policy as Code für Terraform mit OPA und Conftest.

Grenzen der Boundary

Eine Permission Boundary ersetzt keine Identity-based Policy, sie begrenzt nur, was eine solche Policy maximal erlauben darf. Sie wird pro Entität gepflegt, es gibt keinen einzigen Schalter für ein ganzes Konto. Und sie schützt nur, solange die Entität selbst nicht die Rechte hat, die eigene Boundary zu ändern oder zu entfernen. Wer Self-Service-IAM in Terraform oder einer CI-Pipeline aufbaut, braucht deshalb von Anfang an beides: eine Boundary mit begrenztem Scope für den eigentlichen Zweck und einen expliziten Deny gegen deren eigene Veränderung.

Fragen oder Anmerkungen zu diesem Setup: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.