AWS CDK und die versteckten Risiken von Least Privilege

Haben wir das Prinzip der geringsten Privilegien aufgegeben? Ich persönlich bin ein großer Fan davon. Aber seien wir ehrlich, es kann auch schwierig sein, das Prinzip strikt zu befolgen. Mit dem Aufstieg von CDK ist es noch schwieriger geworden.

Warum macht CDK es schwieriger?

CDK ist ein großartiges Werkzeug, wenn Sie Ihre Infrastruktur entwickeln. Mit den Level 1 und Level 2 Konstrukten können Sie ganz einfach Ressourcen erstellen. So weit, so gut. Das Problem liegt bei den Level 2-Konstrukten. Sie sind etwas eigenwillig, was ihre Verwendung angeht. Wenn Sie zum Beispiel Geheimnisse in der Cloud speichern möchten, erstellen Sie ein Geheimnis im Secret Manager. Dieses Geheimnis muss verschlüsselt werden, also werden wir KMS verwenden. Dies kann ganz einfach über CDK erreicht werden:

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 Codebeispiel sehen können. Wir verwenden einen vom Kunden verwalteten KMS-Schlüssel. Wir tun dies, weil wir kontrollieren möchten, wer den Schlüssel für die Entschlüsselung verwenden kann. Die Tatsache, dass Sie den Schlüssel an das Secret-Konstrukt übergeben, bedeutet, dass CDK Ihnen hilft und eine Richtlinie zu Ihrem KMS-Schlüssel hinzufügt. Die Richtlinie, die hinzugefügt wird, 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 ist die einzige Möglichkeit, dies zu umgehen, die Verwendung der Level 1-Konstrukte. Diese Konstrukte sind nicht meinungsbildend und stellen eine Eins-zu-Eins-Zuordnung zu den CloudFromation-Ressourcen dar. Mit diesen Level 1-Konstrukten können Sie den KMS-Schlüssel angeben, ohne die Schlüsselrichtlinie für Sie zu ändern. Die Kehrseite ist, dass Sie allen Prinzipalen, die das Geheimnis in Ihrer KMS-Schlüsselrichtlinie lesen müssen, dies erlauben müssen.

Fazit

Zusammenfassend lässt sich sagen, dass CDK zwar die Entwicklung von Infrastrukturen erheblich vereinfacht, aber ungewollt strenge Least Privilege-Praktiken schwächen kann, insbesondere bei KMS-Schlüsselrichtlinien. Möglicherweise müssen Sie auf Level 1-Konstrukte zurückgreifen, um eine strengere Kontrolle aufrechtzuerhalten, wobei Sie einen gewissen Komfort gegen die Präzision und Sicherheit eintauschen, die Ihre Workloads verdienen.

Foto von AS Photography