Infrastructure-Drift und nicht verwaltete Ressourcen mit Snyk IaC erkennen

Als Entwickler verwenden Sie wahrscheinlich einen Cloud-Infrastrukturanbieter. Und vermutlich automatisieren Sie Teile Ihrer Infrastruktur mit Infrastructure as Code (IaC), damit Bereitstellungen wiederholbar, konsistent und einfach durchzuführen sind – und insgesamt sicherer, weil Parameter im Code besser sichtbar sind.

Letztendlich haben wir alle laufende Ressourcen bei unserem Cloud-Anbieter, kennen aber möglicherweise nicht den aktuellen Zustand aller Ressourcen. Hat jemand eine Einstellung für einen S3-Bucket manuell geändert? Hat ein Kollege einen neuen Pfad in unserer API-Gateway-Bereitstellung erstellt? Woher wissen wir, ob Standardeinstellungen von Ressourcen falsch konfiguriert sind? Früher oder später gibt es Ressourcen im Cloud-Konto, die in keiner Terraform-Bereitstellung auftauchen, geändert oder vollständig gelöscht wurden. Diese Lücke zwischen unserer Vorstellung davon, wie Cloud-Ressourcen konfiguriert sind, und ihrer tatsächlichen Konfiguration wird als Infrastructure-Drift bezeichnet.

Snyk Infrastructure as Code (Snyk IaC) erkennt jetzt alle Arten von Infrastructure-Drift und meldet sie als Terraform-Ressourcen. So erhalten Entwickler vollständige Transparenz und können frühzeitig Abhilfe schaffen.Das umfasst Änderungen oder Löschungen von „verwalteten“ Ressourcen (Ressourcen, die tatsächlich über IaC bereitgestellt wurden) und „nicht verwalteten“ Ressourcen (also Ressourcen, die noch nicht unter IaC-Kontrolle stehen). Die von der Snyk CLI erstellten Berichte lassen sich direkt im Terminal auslesen, in eine Pipeline oder regelmäßige Prüfung integrieren oder zur Weitergabe als HTML exportieren.

Snyk unterstützt alle Terraform-Statusdateien und speichert sie lokal auf allen Blob-Speichern wie Amazon S3, GCS, Azure, HTTPS, Terraform Cloud und mehr. Sie können Speicher kombinieren, um die Struktur Ihrer IaC abzubilden – egal, ob Sie mehrere Terraform-Repositories in verschiedenen Teams oder ein stärker zentralisiertes Modell verwenden. Außerdem funktioniert die Lösung mit allen großen Cloud-Anbietern – AWS, GCP und Azure – und erfordert so wenige Zugriffsrechte wie möglich.

In diesem Blog zeigen wir einige Probleme auf, die sich mit dem Drift-Management von Snyk IaC lösen lassen, darunter:

• Die IaC-Abdeckung in Ihren Cloud-Umgebungen erhöhen

• Infrastructure-Drift in einem Feature oder einer Anwendung sichtbar machen

• Drift in einem bestimmten Cloud-Service erkennen

Vorteile des Drift-Managements

Dies ist die Geschichte eines Services und vieler Ressourcen. Nehmen wir als einfaches Beispiel eine API-Gateway-Bereitstellung. In AWS ist die Verwaltung komfortabel in die Webkonsole integriert. In Terraform ist sie – je nach Version des API-Gateways – auf 10 bis 25 Ressourcen aufgeteilt. Methoden, Antworten, Modelle, Routen, Stages … all das sind unterschiedliche Ressourcen.

Wenn Sie Terraform-Code für vorhandene Services schreiben möchten, ist eine vollständige Liste nicht verwalteter Terraform-Ressourcen, kategorisiert nach Cloud-Service und Ressourcentyp, sehr hilfreich. So erhalten Sie einen guten Überblick und sparen viel Zeit, verglichen damit, die Struktur jeder einzelnen Cloud-Service-Funktion in Terraform zu untersuchen.

Wenn unser API-Gateway bereits in Terraform verwaltet wird, kann trotzdem jeder manuell eine Route oder HTTP-Antwort hinzufügen – und womöglich erfährt niemand davon! Die Drift-Erkennung sorgt dafür, dass solche Änderungen erkannt und gemeldet werden, um mögliche Inkonsistenzen oder Konfigurationsprobleme zu vermeiden.

Kurz gesagt: Wir möchten Drift sichtbar machen, um:

• Unsere Code-Abdeckung zu verbessern, damit der Code vor der Bereitstellung auf Fehlkonfigurationen analysiert werden kann.

• Sofort Maßnahmen zu ergreifen, etwa die Ressource zu löschen oder die Änderung rückgängig zu machen, bevor Schaden entsteht.

Ihre IaC-Abdeckung erhöhen

Wenn es Ihnen wie vielen Teams geht, ist vermutlich noch nicht alles in den zahlreichen Terraform-Repositories abgedeckt, die Sie teamübergreifend nutzen und gemeinsam verwalten. Wie funktioniert also die Erkennung nicht verwalteter Ressourcen in Snyk IaC?

Snyk IaC führt alle Terraform-Statusdateien, die Sie bereitstellen, in einer großen, aggregierten Übersicht zusammen und vergleicht diese mit den Ressourcen in Ihrem AWS-Konto. Die Unterschiede sind Drift und werden als Terraform-Ressourcen gemeldet.

Mit describe von Snyk IaC und der Option --only-unmanaged erreichen wir genau das:

1$ snyk iac describe --only-unmanaged
2[...]
3Snyk Scanning Infrastructure As Code Discrepancies...
4
5  Info:    Resources under IaC, but different to terraform states.
6  Resolve: Reapply IaC resources or update into terraform.
7
8Unmanaged resources: 5
9
10Service: aws_iam [ Unmanaged Resources: 3 ]
11
12  Resource Type: aws_iam_policy_attachment
13    ID: user1-84i30k-arn:aws:iam::aws:policy/AdministratorAccess
14
15  Resource Type: aws_iam_user
16    ID: labs
17
18  Resource Type: aws_iam_user_policy
19    ID: dat-user:manuals3policy
20
21Service: aws_s3 [ Unmanaged Resources: 2 ]
22
23  Resource Type: aws_s3_bucket
24    ID: manual-bucket-2022
25    ID: test-resource-exposure-caxyxllsajfrzbwe
26
27Test Summary
28
29  Managed Resources: 4
30  Unmanaged Resources: 5
31
32  IaC Coverage: 44%

Als Entwickler können wir diese Ausgabe ganz einfach nutzen:

• Zunächst sehen wir, dass unsere Code-Abdeckung bei 44 % liegt. So lässt sich der Fortschritt auf dem Weg zu IaC leichter verfolgen.

• Zwei S3-Buckets (Typ: aws_s3_bucket) sind nicht in Terraform erfasst; ihre Namen werden ebenfalls angezeigt. Wir können sie ganz einfach importieren oder löschen.

• In unserer IAM-Konfiguration gibt es einige Inkonsistenzen:

  • Ein IAM-Benutzer namens „labs“ wurde manuell erstellt (Typ: aws_iam_user_policy). Was macht dieser Benutzer?

  • Eine Zugriffsrichtlinie namens „Administrator“ wurde manuell einem verwalteten IAM-Benutzer namens „user1-84i30k“ zugewiesen (Typ: aws_iam_policy_attachment). Sind sich unsere Teams der Folgen bewusst?

  • Eine vollständige IAM-Richtlinie wurde manuell hinzugefügt (Typ aws_iam_user_policy). Wer kontrolliert ihren Inhalt, wenn jemand sie ändert?

Änderungen seit Ihrer letzten Bereitstellung sichtbar machen

Ein weiterer häufiger Anwendungsfall für Entwickler ist das Drift-Management in einem bestimmten Bereich. Oft sind Entwickler für ein bestimmtes Feature mit einem klar abgegrenzten Infrastrukturumfang verantwortlich. Wir müssen erkennen, was sich in diesem definierten Bereich geändert hat, statt Rückmeldungen zum gesamten Cloud-Konto zu erhalten.

Eine erste Möglichkeit besteht darin, einfach alle Terraform-Statusdateien an Snyk IaC zu übergeben und herauszufinden, welche Ressourcen fehlen und welche davon geändert wurden:

1$ snyk iac describe --only-managed
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Changed resources: 1
8
9State: tfstate://terraform.tfstate [ Changed Resources: 1 ]
10
11  Resource Type: aws_s3_bucket
12    ID: somebucket-84i30k
13    ~ versioning.0.enabled: false => true
14
15Missing resources: 1
16
17State: Generated [ Missing Resources: 1 ]
18
19  Resource Type: aws_iam_policy_attachment
20    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
21
22Test Summary
23
24  Managed Resources: 3
25  Changed Resources: 1
26  Missing Resources: 1
27
28  IaC Coverage: 75%

Dieser Bericht liefert einige interessante Informationen:

• Wir können alle verwendeten Terraform-Statusdateien zusammenführen und trotzdem nur für diesen Bereich Drift-Informationen abrufen.

• Der Bericht zeigt, in welcher Terraform-Statusdatei jede Abweichung oder Änderung gefunden wurde.

• Diese Funktion ist ressourcenschonend und erfordert nur minimale Zugriffsrechte auf das Cloud-Konto. Verwenden Sie dafür keinesfalls die Zugangsdaten für Terraform-Bereitstellungen in CI/CD!

Fehlende Ressourcen in einem Cloud-Service erkennen

Als Entwickler möchten wir möglicherweise nur einen einzelnen Cloud-Service genauer überprüfen, zum Beispiel „S3“ oder „IAM“. Dafür können wir Ressourcenfilter in Snyk IaC verwenden (--filter="aws_resource_name"). Dazu müssten wir jedoch alle Ressourcen kennen und auflisten und die Liste anschließend aktuell halten. Das ist mühsam! Mit der Option --service beziehen wir stattdessen einen gesamten Service ein, ohne wissen zu müssen, wie viele Ressourcen betroffen sind.

1$ snyk iac describe --only-managed --service=aws_iam
2Snyk Scanning Infrastructure As Code Discrepancies...
3
4  Info:    Resources under IaC, but different to terraform states.
5  Resolve: Reapply IaC resources or update into terraform.
6
7Missing resources: 1
8
9State: Generated [ Missing Resources: 1 ]
10
11  Resource Type: aws_iam_policy_attachment
12    ID: user1-84i30k-arn:aws:iam::aws:policy/ReadOnlyAccess
13
14Test Summary
15
16  Managed Resources: 2
17  Missing Resources: 1
18
19  IaC Coverage: 66%
20  Info: To reach full coverage, remove resources or move it to Terraform.

In diesem Anwendungsfall erhalten wir einen Bericht zu allen Ressourcen des AWS-IAM-Services. Damit werden auf einen Schlag problemlos Dutzende Terraform-Ressourcen abgedeckt, etwa Zugriffsschlüssel, Gruppen, Zuordnungen, Richtlinien und Rollen.

Drift-Management jetzt in Snyk IaC verfügbar

Ganz gleich, ob Sie als Entwickler gerade mit IaC beginnen oder zu einem erfahrenen Team mit etablierten und ausgefeilten IaC-Workflows gehören: Das Drift-Management in Snyk IaC hilft Ihnen, besser zu erkennen, was in Ihren Cloud-Konten tatsächlich ausgeführt wird, und schnell zu handeln – mit möglichst geringen Zugriffsrechten.

Das Drift-Management von Snyk IaC lässt sich bei Bedarf lokal über die CLI auf Entwickler-Laptops, in CI/CD-Pipelines oder als regelmäßig geplanter Cron-Job ausführen, um gezielte Berichte zu erstellen (ab Version 1.918.0).

Das Drift-Management ist in allen Snyk-Plänen verfügbar, einschließlich unseres Free-Plans. Beginnen Sie noch heute damit, Ihre Infrastruktur als Code zu schützen.