Cloud-Ressourcen umfassender erfassen, um Infrastrukturabweichungen zu reduzieren

Als Entwickler benötigen wir maximale Transparenz darüber, was tatsächlich in unseren Cloud-Umgebungen ausgeführt wird, um sie sicher zu halten. Mit Infrastructure as Code (IaC) können Entwickler ihre Cloud-Infrastrukturen automatisieren. So behalten sie die Kontrolle über die in der Cloud bereitgestellten Ressourcen und können diese problemlos überprüfen. Eine vollständige IaC-Abdeckung Ihrer Infrastruktur zu erreichen und aufrechtzuerhalten, bringt jedoch viele Herausforderungen mit sich.

Unsere Sicherheit ist nur so gut wie das, was tatsächlich in unseren Cloud-Umgebungen bereitgestellt wird und läuft. Häufig werden regelmäßig noch viele manuelle Änderungen vorgenommen – von uns, anderen Teams oder authentifizierten Diensten. Diese Änderungen sind für IaC und Audits nicht sichtbar und können zu Problemen wie Fehlkonfigurationen und Sicherheitsrisiken führen. Genau deshalb ist das Management von Abweichungen wichtig: Wir benötigen Berichte über Ressourcen, die noch nicht durch IaC verwaltet werden oder aus irgendeinem Grund geändert wurden.

In diesem Artikel zeigen wir, wie Snyk IaC Entwickler dabei unterstützt, Cloud-Ressourcen zu finden, die nicht durch Infrastructure as Code (IaC) verwaltet werden (nicht verwaltete Ressourcen) oder von ihrem erwarteten Zustand abweichen (verwaltete Ressourcen).

Umgebung einrichten

Mit Snyk IaC können Sie die gefundenen Ressourcen als Terraform-Ressourcen auflisten. So sehen Sie leicht, welcher Teil des Cloud-Dienstes von der Erkennung betroffen ist. Ein einzelner Amazon-API-Gateway-v2-Dienst besteht beispielsweise aus mindestens 12 Terraform-Ressourcen. Dank der von Snyk bereitgestellten Erkennungsinformationen können Sie schnell entscheiden, ob Sie die Änderung rückgängig machen, eine neue Ressource importieren oder die neue Änderung einfach löschen möchten.

Für die Anleitung können Sie die folgende Terraform-Datei verwenden, um zwei AWS-Ressourcen zu erstellen. Wir verwenden sie im weiteren Verlauf. Sie erstellt einen IAM-Benutzer namens „user1“ mit einem zufälligen Suffix, einen Zugriffsschlüssel und eine angehängte Richtlinie mit schreibgeschütztem Zugriff.

Zum Zeitpunkt der Erstellung dieses Artikels haben wir Terraform v1.1.7 mit dem AWS-Provider v3.74.2 verwendet.

Verwenden Sie die folgende HCL-Konfiguration erneut:

main.tf

1resource "random_string" "prefix" {
2  length  = 6
3  upper   = false
4  special = false
5}
6
7resource "aws_iam_user" "user1" {
8  name = "user1-${random_string.prefix.result}"
9
10  tags = {
11    Name = "user1-${random_string.prefix.result}"
12    manual = "true"
13  }
14}
15
16resource "aws_iam_access_key" "user1" {
17  user = aws_iam_user.user1.name
18}
19
20resource "aws_iam_user_policy_attachment" "user1" {
21  user       = aws_iam_user.user1.name
22  policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
23}

Wenden Sie diese Terraform-Konfiguration an:

1$ terraform init
2[...]
3$ terraform apply
4[...]

Vergewissern Sie sich, dass sich im Stammverzeichnis des Verzeichnisses eine terraform.tfstate befindet:

1$ ls -al terraform.tfstate
2-rw-r--r--  1 sjourdan  staff  5049 Mar 16 18:31 terraform.tfstate

Vergewissern Sie sich außerdem, dass der IAM-Benutzer erfolgreich in AWS erstellt wurde.

Mit einer sauberen Ausgangsbasis beginnen

Listen wir zunächst alle Cloud-Ressourcen auf, die nicht von Terraform verwaltet werden:

1$ snyk iac describe --only-unmanaged

Wahrscheinlich erhalten Sie eine umfangreiche Liste mit Ressourcen, die nicht von Terraform verwaltet werden. Das sind zwar nützliche Informationen, für unseren Anwendungsfall jedoch nicht sehr handlungsrelevant. Snyk IaC bietet eine integrierte Möglichkeit, Ressourcen gesammelt zu ignorieren, indem alle gefundenen Ressourcen zur Richtliniendatei .snyk hinzugefügt werden.

Ignorieren wir alle vorhandenen, nicht verwalteten Ressourcen, damit wir in einer kontrollierten Umgebung präziser arbeiten können – nur mit den beiden oben erstellten Ressourcen:

1$ snyk iac describe --only-unmanaged --json  | snyk iac update-exclude-policy

Führen Sie erneut einen Scan durch, um zu bestätigen, dass Ihre Umgebung die erkannten Abweichungen jetzt ignoriert. (Sie haben später noch genügend Zeit, den Import dieser Ressourcen zu planen.) 

1$ snyk iac describe --only-unmanaged
2
3Scanned states (1)
4Found 3 resource(s)
5 - 100% coverage
6Congrats! Your infrastructure is fully in sync.

Jetzt können wir mit einer sauberen Ausgangsbasis beginnen.

Abweichungen mit IAM erzeugen

Wir erzeugen nun drei Arten von Abweichungen, um Situationen aus der Praxis nachzustellen:

1. Eine Änderung am vorhandenen IAM-Benutzer (die wir rückgängig machen möchten)

2. Eine manuelle Zuordnung einer neuen IAM-Richtlinie (die wir entfernen möchten)

3. Ein neuer IAM-Benutzer (den wir verbessern möchten)

Navigieren Sie dazu zur AWS-IAM-Konsole.

Vorhandenen IAM-Benutzer durch Hinzufügen eines Tags ändern

1. Klicken Sie auf der Seite „IAM-Benutzer“ auf „user1“.

2. Klicken Sie auf den Tab Tags.

3. Klicken Sie auf die Schaltfläche Edit Tags.

4. Fügen Sie einen neuen Schlüssel („environment“) und einen neuen Wert („production“) hinzu.

5. Klicken Sie auf Save.

Vorhandenem IAM-Benutzer eine leistungsstarke Richtlinie zuordnen

1. Klicken Sie auf der Seite „IAM-Benutzer“ auf „user1“.

2. Klicken Sie auf den Tab Permissions.

3. Klicken Sie auf die Schaltfläche Add permissions.

4. Klicken Sie auf Attach existing policies directly.

5. Wählen Sie Administrator Access aus.

6. Klicken Sie auf Next: Review.

7. Bestätigen Sie mit einem Klick auf Add permissions.

Manuell einen weiteren IAM-Benutzer erstellen

1. Klicken Sie auf der Seite „IAM-Benutzer“ auf die Schaltfläche Add Users.

2. Geben Sie im Feld User name: „user2“ ein.

3. Wählen Sie Access key aus.

4. Klicken Sie auf die Schaltfläche Next: Permissions.

5. Legen Sie keine Berechtigungen oder Tags fest.

6. Klicken Sie auf Create user (die angezeigten Anmeldedaten sind nicht relevant und können verworfen werden).

Jetzt können wir diese manuellen Änderungen mit der Erkennung von Abweichungen in Snyk IaC angehen.

Abweichungen bei verwalteter und nicht verwalteter Infrastruktur

Sehen wir uns nun an, wie Snyk IaC diese Änderungen erkennt. Beginnen wir mit Ressourcen, die überhaupt nicht von Terraform verwaltet werden.

1$ snyk iac describe --only-unmanaged
2
3Scanned states (1)
4Found resources not covered by IaC:
5  aws_iam_access_key:
6    - AKIASBXWQ3AYQETE6OFR
7        User: user2
8  aws_iam_policy_attachment:
9    - user1-84i30k-arn:aws:iam::aws:policy/AdministratorAccess
10  aws_iam_user:
11    - user2
12Found 6 resource(s)
13 - 50% coverage
14 - 3 resource(s) managed by Terraform
15 - 3 resource(s) not managed by Terraform
16 - 0 resource(s) found in a Terraform state but missing on the cloud provider

Dieser Scan meldet die folgenden Ressourcen nach Terraform-Begriffen:

• Den manuell erstellten IAM-Benutzer „user2“ mit seinem IAM-Zugriffsschlüssel

• Die manuell an den von Terraform verwalteten IAM-Benutzer „user1“ angehängte IAM-Richtlinie.

Prüfen wir nun ausschließlich Änderungen an Ressourcen, die von Terraform verwaltet und in den verschiedenen Terraform-Statusdateien gefunden werden:

1$ snyk iac describe –only-managed
2Scanned states (1)
3Found changed resources:
4  From tfstate://terraform.tfstate
5    - user1-84i30k (aws_iam_user.user1):
6        + tags.environment: <nil> => "production"
7Found 5 resource(s)
8 - 100% coverage
9 - 5 resource(s) managed by Terraform
10     - 1/5 resource(s) out of sync with Terraform state
11 - 0 resource(s) found in a Terraform state but missing on the cloud provider

Dieser Scan lieferte eine ganz andere Ausgabe und dauerte deutlich länger (36 s gegenüber 9 s im Scan-Modus für „nicht verwaltete“ Ressourcen).

Anhand dieser Ausgabe erfahren wir, dass der IAM-Benutzer „user1-84i30k“, den wir in HCL als Ressource unter dem Namen „user1“ finden, ein Tag namens „environment“ mit dem Wert „production“ hat.

Aktionsplan

Mit dem Snyk-Tool zur Erkennung von Abweichungen haben wir vier unerwartete Unterschiede zwischen unseren Erwartungen und der Realität entdeckt. Für diesen Artikel nehmen wir an, dass das Team Folgendes beschließt:

• Der IAM-Benutzer „user2“ wird in der Produktion verwendet und sollte in Terraform importiert werden.

• Der IAM-Zugriffsschlüssel von „user2“ sollte aus Sicherheitsgründen rotiert werden.

• „user1“ darf unter keinen Umständen Administrator sein.

• Das neue Tag für „user1“ wird aufgrund einer Anforderung benötigt und sollte in Terraform importiert werden.

Deployment-Pipelines sind keine Abhilfe

Wir haben eine gute Terraform-Deployment-Pipeline eingerichtet. Wenn das nächste Mal terraform apply ausgeführt wird, erwarten wir vielleicht, dass alles wieder normal ist.

Was wird Terraform in diesem Fall tun? Ein Deployment-Job:

1$ terraform apply
2Terraform will perform the following actions:
3
4  # aws_iam_user.user1 will be updated in-place
5  ~ resource "aws_iam_user" "user1" {
6        id            = "user1-84i30k"
7        name          = "user1-84i30k"
8      ~ tags          = {
9          - "environment" = "production" -> null
10            # (1 unchanged element hidden)
11        }
12[...]
13
14Plan: 0 to add, 1 to change, 0 to destroy.

Terraform war nie dafür vorgesehen, manuell erstellte oder zugeordnete Ressourcen zu erkennen. Es setzt geänderte Ressourcen einfach auf den ursprünglichen Zustand zurück – was wir in diesem Fall nicht möchten.

In keinem der Fälle erhalten wir die erwartete Unterstützung:

• Der manuell erstellte IAM-Benutzer und sein Zugriffsschlüssel werden nicht gemeldet (nicht hilfreich).

• Die manuell angehängte Administrator-Richtlinie eines verwalteten Benutzers wird nicht gemeldet (nicht hilfreich).

• Das wichtige Tag, das manuell für einen verwalteten Benutzer hinzugefügt wurde, wird zurückgesetzt (schädlich).

Für diese Art der Erkennung und Bearbeitung wird ein anderes Tool benötigt.

Unsere Abdeckung verbessern

Bei nicht verwalteten Ressourcen starten wir mit einer Abdeckung von 50 %:

1$ snyk iac describe --only-unmanaged
2
3Scanned states (1)
4Found resources not covered by IaC:
5  aws_iam_access_key:
6    - AKIASBXWQ3AYQETE6OFR
7        User: user2
8  aws_iam_policy_attachment:
9    - user1-84i30k-arn:aws:iam::aws:policy/AdministratorAccess
10  aws_iam_user:
11    - user2
12Found 6 resource(s)
13 - 50% coverage
14 - 3 resource(s) managed by Terraform
15 - 3 resource(s) not managed by Terraform
16 - 0 resource(s) found in a Terraform state but missing on the cloud provider

Verbessern wir sie anhand des Teamplans.

IAM-Richtlinie für „user1“ löschen

Beginnen wir mit der dringendsten und einfachsten Maßnahme: Entfernen der Richtlinie „Administrator“ für den verwalteten IAM-Benutzer „user1“:

• Navigieren Sie zu IAM > Users > „user1“.

• Klicken Sie auf Permissions > löschen Sie „AdministratorAccess“.

1$ snyk iac describe --only-unmanaged
2Scanned states (1)
3Found resources not covered by IaC:
4  aws_iam_access_key:
5    - AKIASBXWQ3AYQETE6OFR
6        User: user2
7  aws_iam_user:
8    - user2
9Found 5 resource(s)
10 - 60% coverage
11 - 3 resource(s) managed by Terraform
12 - 2 resource(s) not managed by Terraform

Jetzt erfassen wir 60 % unserer AWS-Ressourcen statt 50 %.

Weiter geht’s.

Terraform-Deployment-Pipeline entsperren

Die Pipeline wird derzeit durch diese manuelle Änderung der Tags für aws_iam_user.user1 blockiert. Bei einem Deployment würden die Tags auf die Werte in HCL zurückgesetzt. Was ist also die Lösung? Verwenden Sie die Ausgabe der Snyk-IaC-Abweichungserkennung, um Ihre Terraform-Konfiguration anzupassen.

Uns liegen folgende Informationen vor:

1Found changed resources:
2  From tfstate://terraform.tfstate
3    - user1-84i30k (aws_iam_user.user1):
4        + tags.environment: <nil> => "production"

Aus dieser Ausgabe wissen wir:

• Wir suchen nach einer Ressource vom Typ aws_iam_user mit dem Namen „user1“.

• Diese Ressource ist in terraform.tfstate zu finden (sehr praktisch, wenn Sie Dutzende oder Hunderte von Statusdateien haben).

• Es gibt einen neuen Tag-Schlüssel namens environment mit dem Wert „production“.

Aktualisieren wir einfach unsere IAM-Benutzerressource, indem wir environment = "production" hinzufügen. Dann sieht unsere Ressource so aus:

1resource "aws_iam_user" "user1" {
2 name = "user1-${random_string.prefix.result}"
3
4 tags = {
5   Name = "user1-${random_string.prefix.result}"
6   environment = "production"
7 }
8}

Jetzt können wir unsere Terraform-Deployment-Pipeline bedenkenlos entsperren:

1$ terraform apply
2No changes. Your infrastructure matches the configuration.
3Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Damit haben wir unsere „verwalteten“ Abweichungen vorerst behoben:

1$ snyk iac describe --only-managed
2Scanned states (1)
3Found 3 resource(s)
4 - 100% coverage
5Congrats! Your infrastructure is fully in sync.

IAM-Benutzer user2 importieren und Schlüssel rotieren

Kümmern wir uns nun um „user2“. Wir möchten:

• den Benutzer in Terraform importieren

• den Schlüssel rotieren

Importieren wir zunächst den IAM-Benutzer in Terraform. Hier ist eine einfache Möglichkeit dazu.

Erfassen Sie zunächst die Informationen aus Snyk IaC:

Wie importieren wir eine aws_iam_user resource? Laut der offiziellen Terraform-Dokumentation: IAM-Benutzer können mit ihremNamenimportiert werden, z. B. mit $ terraform import aws_iam_user.lb loadbalancer.

Außerdem erfahren wir, dass nur das Argument name erforderlich ist. Fügen wir also diese einfache Struktur zu unserer HCL-Datei hinzu:

1resource "aws_iam_user" "user2" {
2 name = "user2" # required
3}

Importieren wir diesen Benutzer nun in Terraform:

1$ terraform import aws_iam_user.user2 user2
2aws_iam_user.user2: Importing from ID "user2"...
3aws_iam_user.user2: Import prepared!
4  Prepared aws_iam_user for import
5aws_iam_user.user2: Refreshing state... [id=user2]
6
7Import successful!

Wie hat sich unsere Abdeckung entwickelt? Sehen wir nach:

1$ snyk iac describe --only-unmanaged
2Scanned states (1)
3Found resources not covered by IaC:
4  aws_iam_access_key:
5    - AKIASBXWQ3AYQETE6OFR
6        User: user2
7Found 5 resource(s)
8 - 80% coverage
9 - 4 resource(s) managed by Terraform
10 - 1 resource(s) not managed by Terraform

Jetzt erreichen wir eine Abdeckung von 80 % (zuvor 60 %), und nur eine Ressource bleibt übrig.

Schlüssel rotieren

Kümmern wir uns jetzt darum. Wir möchten den Schlüssel rotieren und ihn gleichzeitig in Terraform aufnehmen. Fügen wir zunächst den neuen Schlüssel zu HCL hinzu, um einen neuen Schlüssel zu erstellen (den wir zum Beispiel dem zuständigen Team geben können). Anschließend löschen wir einfach den alten Schlüssel aus AWS.

Die Terraform-Dokumentation zu aws_iam_access_key ist sehr verständlich. Daher können wir einfach eine Ressource erstellen, für die der Name von user2 als Argument dient:

1resource "aws_iam_access_key" "user2" {
2 user = aws_iam_user.user2.name
3}

Da die Deployment-Pipeline zuvor entsperrt wurde, können wir dies sicher mit Terraform anwenden und einen neuen Schlüssel erstellen:

1$ terraform apply 
2[...]
3Terraform will perform the following actions:
4
5  # aws_iam_access_key.user2 will be created
6  + resource "aws_iam_access_key" "user2" {
7      + create_date          = (known after apply)
8      + encrypted_secret     = (known after apply)
9      + id                   = (known after apply)
10      + key_fingerprint      = (known after apply)
11      + secret               = (sensitive value)
12      + ses_smtp_password_v4 = (sensitive value)
13      + status               = "Active"
14      + user                 = "user2"
15    }
16
17Plan: 1 to add, 0 to change, 0 to destroy.
18
19aws_iam_access_key.user2: Creating...
20aws_iam_access_key.user2: Creation complete after 1s [id=AKIASBXWQ3AY4KPUNIHZ]
21
22Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Der alte Schlüssel muss noch entfernt werden. Anhand der Ausgabe von Snyk IaC wissen wir, dass der Schlüsselname AKIASBXWQ3AYQETE6OFR lautet.

Am einfachsten entfernen Sie diesen Schlüssel wie folgt:

• Navigieren Sie zu IAM > Users > user2 > Security Credentials.

• Entfernen Sie den von Snyk IaC gemeldeten Schlüssel AKIASBXWQ3AYQETE6OFR, indem Sie ihn zunächst deaktivieren und anschließend löschen.

Wie sieht unsere Abdeckung jetzt aus?

1$ snyk iac describe --only-unmanaged
2Scanned states (1)
3Found 5 resource(s)
4 - 100% coverage
5Congrats! Your infrastructure is fully in sync.

Herzlichen Glückwunsch! Dank der Erkennung von Abweichungen in Snyk IaC ist wieder alles unter Kontrolle.

Fazit

In diesem Artikel haben wir gezeigt, wie die Erkennung von Abweichungen in Snyk IaC dabei helfen kann, manuell erstellte AWS-Ressourcen zu finden. Außerdem haben wir gesehen, wie die Ergebnisse in Terraform-Begriffen und mit den erforderlichen Informationen aufbereitet werden, damit Entwickler diese Ressourcen in ihren Terraform-HCL-Code importieren können. Wir haben auch kurz festgestellt, dass Änderungen nicht immer automatisch zurückgesetzt werden sollten und dass zusätzlich zur Deployment-Pipeline ein schlankes Warnsystem zur Erkennung von Abweichungen erforderlich ist.

Wir sind überzeugt, dass die gesamte Infrastruktur als Code vorliegen sollte, damit Entwickler so früh wie möglich Sicherheitsfeedback erhalten und Probleme erkennen können.

Deshalb unterstützt Snyk IaC Teams dabei, alle Ressourcen, die tatsächlich in ihrem AWS-Konto ausgeführt werden, schnell wieder in Terraform-Code zu integrieren, um die IaC-Abdeckung insgesamt zu erhöhen und Sicherheitsprobleme zu reduzieren. Snyk IaC ermöglicht schnellere Fehlerbehebungen, indem es die Feedbackschleife zwischen Cloud-Security- und Engineering-Teams schließt und umsetzbare Lösungen direkt an die zuständigen Engineers meldet – in einer für Engineers verständlichen Sprache.