AWS CDK und die versteckten Risiken von Least Privilege

Haben wir das Prinzip der geringsten Privilegien aufgegeben? Ich persönlich bin ein großer Befürworter davon. Aber seien wir ehrlich: Es kann auch schwierig sein, dieses Prinzip strikt einzuhalten. Mit dem Aufkommen des AWS Cloud Development Kit (AWS CDK) ist dies noch schwieriger geworden.

Warum erschwert AWS CDK die Sache?

AWS CDK ist ein hervorragendes Tool für die Entwicklung Ihrer Infrastruktur. Mit den Konstrukten der Ebenen 1 und 2 können Sie Ressourcen ganz einfach erstellen. Das Problem liegt bei den Konstrukten der Ebene 2. Diese schreiben Ihnen gewissermaßen vor, wie Sie sie verwenden sollten. Wenn Sie beispielsweise Geheimnisse in der Cloud speichern möchten, erstellen Sie ein Geheimnis im Secret Manager. Da dieses Geheimnis verschlüsselt werden muss, verwenden wir den AWS Key Management Service. Dies lässt sich mit AWS CDK ganz einfach bewerkstelligen:

const secret = new secretsmanager.Secret(this, 'Secret', {
 secretName: `MySecret`,
 description: 'My super Secret',
 encryptionKey: kmsKey,
 generateSecretString: {
   secretStringTemplate: JSON.stringify({ username: 'myUser' }),
   generateStringKey: 'password',
 },
});

Wie Sie im Code-Beispiel sehen können, verwenden wir einen vom Kunden verwalteten KMS-Schlüssel. Wir tun dies, weil wir kontrollieren möchten, wer den Schlüssel zur Entschlüsselung verwenden darf. Die Tatsache, dass Sie den Schlüssel an das „Secret“-Konstrukt übergeben, bedeutet, dass AWS CDK Sie dabei unterstützt und Ihrem KMS-Schlüssel eine Richtlinie hinzufügt. Die hinzugefügte Richtlinie lautet wie folgt:

{
 "Effect": "Allow",
 "Principal": {
   "AWS": "arn:aws:iam::000000000000:root"
 },
 "Action": [
   "kms:CreateGrant",
   "kms:Decrypt",
   "kms:DescribeKey",
   "kms:Encrypt",
   "kms:GenerateDataKey*",
   "kms:ReEncrypt*"
 ],
 "Resource": "*",
 "Condition": {
   "StringEquals": {
     "kms:ViaService": "secretsmanager.eu-west-1.amazonaws.com"
   }
 }
}

Diejenigen, die mit KMS-Richtlinien vertraut sind, werden feststellen, dass jeder Principal den Schlüssel nun verwenden kann, wenn er über den Secrets Manager Service verwendet wird. Auf den ersten Blick mögen Sie denken, dass dies nicht so schlimm oder praktisch ist. Das Problem dabei ist jedoch, dass jeder Principal mit einer allow-Anweisung für die Aktion secretsmanager:GetSecretValue in der Lage ist, Ihr Geheimnis zu lesen.

Es wird noch schlimmer

Sie speichern das Geheimnis aus einem bestimmten Grund. Wahrscheinlich müssen Sie es irgendwo in Ihrer Arbeitslast lesen. Dazu müssen Sie eine Rolle erstellen und dieser Rolle die Rechte zum Lesen des Geheimnisses erteilen. Dies ist mit CDK ganz einfach möglich.

secret.grantRead(role)

Aber diese einfache Anweisung ändert erneut die KMS-Richtlinie. Es wird die folgende Richtlinie hinzugefügt.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::000000000000:role/MyRole"
  },
  "Action": [
    "kms:Decrypt",
    "kms:Encrypt",
    "kms:GenerateDataKey*",
    "kms:ReEncrypt*"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "secretsmanager.eu-west-1.amazonaws.com"
    }
  }
}

Zumindest ist sie auf die Rolle zugeschnitten, und das ist es, was Sie wollen. Aber erinnern Sie sich an die vorherige Richtlinie? Sie erlaubt bereits allen Prinzipalen, diesen Schlüssel zu verwenden.

Wie lässt sich das umgehen?

Leider besteht die einzige Möglichkeit, dies zu umgehen, darin, die Level-1-Konstrukte zu verwenden. Diese Konstrukte sind nicht voreingenommen und bilden eine Eins-zu-Eins-Zuordnung zu den AWS CloudFormation -Ressourcen. Mit diesen Level-1-Konstrukten können Sie den KMS-Schlüssel angeben, ohne die Schlüsselrichtlinie ändern zu müssen. Der Nachteil ist, dass Sie in Ihrer KMS-Schlüsselrichtlinie allen Prinzipalen, die das Geheimnis lesen müssen, Zugriff gewähren müssen.

Fazit

Zusammenfassend lässt sich sagen: Obwohl AWS CDK die Infrastrukturentwicklung erheblich vereinfacht, kann es unbeabsichtigt strenge „Least Privilege“-Praktiken untergraben, insbesondere im Zusammenhang mit KMS-Schlüsselrichtlinien. Möglicherweise müssen Sie auf Konstrukte der Stufe 1 zurückgreifen, um eine strengere Kontrolle zu gewährleisten, und dabei etwas Komfort gegen die Präzision und Sicherheit eintauschen, die Ihre Workloads verdienen.

Foto: AS Photography