Erkennung von Infrastruktur-Drift und nicht verwalteten Ressourcen mit Snyk IaC

Für die Entwicklung ihrer Software greifen Developer heute zunehmend auf Infrastruktur von Cloud-Providern zurück. Häufig wird dabei zur Automatisierung Infrastructure as Code (IaC) genutzt, macht diese Methodik Deployments doch konsistent wiederholbar, einfach zu implementieren und insgesamt sicherer, da die zugehörigen Parameter über den Code transparent abgebildet werden.

So werden letztlich alle Live-Ressourcen über den Service des Cloud-Providers ausgeführt. Dabei ist jedoch nicht unbedingt klar, wie es um den Status quo dieser Ressourcen bestellt ist. Denn womöglich hat ein Entwickler etwa eine Definition für einen S3-Bucket manuell geändert oder einen neuen Pfad im Deployment des API-Gateways eingerichtet. Auch wäre es möglich, dass wichtige Standardressourcen falsch konfiguriert sind. Dies mit dem Ergebnis, dass auf dem Cloud-Account Ressourcen ausgeführt werden, die entweder überhaupt nicht in einem Terraform-Deployment enthalten sind, oder aber geändert oder auch komplett gelöscht wurden. Diese Diskrepanz zwischen der vorgesehenen und tatsächlichen Konfiguration wird als Infrastruktur-Drift bezeichnet.

Snyk Infrastructure as Code (Snyk IaC) macht ab sofort die Erkennung aller Arten von Infrastruktur-Drift möglich und liefert Scan-Ergebnisse in Form von Terraform-Ressourcen.Entwickler erhalten so umfassende Visibility und können Fixings frühzeitig einsteuern. Dies für geänderte oder gelöschte „verwaltete“, also via IaC umgesetzte Deployments, ebenso wie für „nicht verwaltete“ Ressourcen, die noch nicht unter IaC-Kontrolle stehen.  Die Scan-Ergebnisse aus der Snyk CLI können direkt über das Terminal ausgelesen, in eine Pipeline oder regelmäßig durchgeführte Checks integriert oder auch zum Austausch im Team als HTML exportiert werden.

Snyk unterstützt alle Terraform-States und speichert diese Dateien lokal auf allen Blob-Storage-Lösungen wie Amazon S3, GCS, Azure, HTTPS, Terraform Cloud und mehr. Der Speicher ist dabei beliebig gemäß Ihrer IaC-Struktur kombinierbar, unabhängig davon, ob bei Ihnen verschiedene Teams jeweils eigene Terraform-Repositories nutzen oder alles über ein zentralisiertes Modell läuft.  Abgedeckt werden hierzu von AWS und GCP bis hin zu Azure alle gängigen Cloud-Provider, dies bei einem Mindestmaß an Zugriffsrechten für Ihre Infrastruktur.

Im Folgenden gehen wir auf einige der wichtigsten Problemstellungen rund um Drift-Management ein, die sich mit Snyk IaC adressieren lassen. Dazu gehören:

• Erhöhung der IaC-Abdeckung in Ihrer Cloud-Umgebung

• Identifikation von Infrastruktur-Drift innerhalb von Features oder Anwendungen

• Erkennung von Drift innerhalb bestimmter Cloud-Services

Vorteile von Drift-Management

Im Kern geht es dabei um die Problematik, dass hinter einem Service eine große Zahl einzelner Ressourcen stehen. Deutlich wird dies etwa bei einem simplen Deployment eines API-Gateways: In AWS lässt sich dies komplett integriert über die Web-Konsole umsetzen, in Terraform liegen dem jedoch abhängig von der Version des API-Gateways zwischen 10 und 25 Ressourcen zugrunde. So etwa Ihre Methoden und erhaltenen Antworten, die Modelle, Routen und Stages: Sie alle stellen jeweils eigene Ressourcen dar.

Wollen Sie nun Ihre bestehenden Services in Terraform-Code abbilden, ist eine Liste aller nicht verwalteter Terraform-Ressourcen daher enorm hilfreich. Dies umso mehr, wenn die Ressourcen darin nach Typ sowie dem ihr zugehörigen Cloud-Service kategorisiert werden. Andernfalls müssten Sie zunächst unter enormem Zeitaufwand herausfinden, wie jede einzelne Cloud-Service-Funktionalität in Terraform strukturiert ist.

Und selbst nachdem wir das API-Gateway in Terraform unter Kontrolle haben, könnte ihm noch immer eine Route oder etwa auch eine HTTP-Antwort manuell hinzugefügt werden, ohne dass wir davon überhaupt Notiz nehmen. Aufschluss über eben solche Änderungen erhalten Sie mittels Drift-Erkennung. Potenziell inkonsistente oder problematische Konfigurationen lassen sich so auf ein Minimum reduzieren.

Wichtig ist Visibility für Drifts daher insbesondere aus zwei Gründen:

• Erhöhung der IaC-Abdeckung, um Code noch vor seinem Deployment auf Fehlkonfigurationen analysieren zu können

• Umgehende Reaktion etwa durch Löschen oder Wiederherstellen der ursprünglichen Konfiguration einer Ressource, bevor daraus Probleme entstehen können

Erhöhung der IaC-Abdeckung

Angesichts der diversen Terraform-Repositories, die viele Entwicklerteams für ihre diversen Projekte gemeinsam nutzen, ist es zumindest wahrscheinlich, dass dieses komplexe Geflecht nicht vollständig via IaC verwaltet ist. Die Erkennung dieser nicht verwalteten Ressourcen löst Snyk IaC anhand einer strukturierten Methodik.

Sämtliche Terraform-States, die Sie mit Snyk IaC analysieren, werden in einer umfassenden Aufstellung zusammengeführt und mit den Ressourcen in Ihrem AWS-Account abgeglichen. Die dabei festgestellten Abweichungen bzw. Drifts gibt die Lösung dann in Form von Terraform-Ressourcen aus.

Umgesetzt wird dies in Snyk IaC über den Befehl describe mit dem Zusatz --only-unmanaged, wie im nachfolgenden Screenshot gezeigt:

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%

Das Ergebnis liefert uns als Entwickler äußerst nützliche Informationen:

• In der Zusammenfassung am Ende haben wir mit 44 % den aktuellen Wert der IaC-Abdeckung. Damit können wir unsere Fortschritte auf dem Weg zu ihrer Erhöhung einfach im Blick behalten.

• In den Zeilen darüber sehen wir, dass zwei S3-Buckets vom Typ aws_s3_bucket nicht in Terraform verwaltet werden und erhalten dabei auch Aufschluss über ihre Namen. So können wir direkt entscheiden, ob wir sie in Terraform importieren oder löschen möchten.

• Festgestellt wurden zudem einige Inkonsistenzen in unserer IAM-Konfiguration: 

  • Ein IAM-Benutzer namens „labs“ (vom Typ aws_iam_user_policy) wurde manuell erstellt. Hier sollten wir prüfen, welche Aktionen dieser Benutzer ausführen kann.

  • Dem verwalteten IAM-Benutzer „user1-84i30k“ vom Typ aws_iam_policy_attachment wurde durch manuelle Ergänzung der Policy „AdministratorAccess“ Zugriff als Administrator gewährt. Hier gilt es festzustellen, ob die Folgen davon für alle unsere Teams klar und akzeptabel sind.

  • Bei der kompletten IAM-Policy vom Typ aws_iam_user_policy, die ebenfalls manuell hinzugefügt wurde, gilt es zu untersuchen, durch wen ihr Inhalt im Falle einer Änderung kontrolliert wird.

Identifikation von Änderungen nach letztem Deployment

Häufig ist es für Entwickler zudem wichtig, Drift nur in dem spezifischen Bereich der Infrastruktur erkennen zu können, der dem von ihnen jeweils verantworteten Feature zugrunde liegt. Bei diesem Use Case geht es also darum, Änderungen für einen klar definierten Bereich und nicht für den gesamten Cloud-Account aufzudecken.

Mit Snyk IaC führen wir hierzu einfach einen Scan auf sämtliche Terraform-States aus. Daraus können wir dann feststellen, welche Ressourcen noch nicht abgedeckt werden und bei welchen Abweichungen vorliegen.

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%

Ein Blick auf den Report macht dies deutlich:

• Wir haben zwar alle von uns genutzten Terraform-States analysiert, können aber erkennen, an welchen Punkten des für uns relevanten Perimeter Drift vorliegt.

• Drift bzw. Änderungen werden nach dem Terraform-State aufgeschlüsselt, in dem diese festgestellt wurden.

• Wichtig zudem: Snyk IaC kommt für all dies mit Zugriff auf den Cloud-Account aus, benötigt also keinerlei Anmeldedaten für Ihr CI/CD-Deployment in Terraform.

Erkennung nicht abgedeckter Ressourcen innerhalb eines Cloud-Service

Um einen einzelnen Cloud-Service wie etwa S3 oder IAM auf Drift auszuleuchten, wäre eine Möglichkeit, mit Snyk IaC über --filter="aws_resource_name" nach den entsprechenden Ressourcen filtern. Hierzu müssten wir allerdings die Namen sämtlicher Ressourcen kennen, diese auflisten und die Liste zudem manuell aktualisieren. Ein reichlich aufwändiges Unterfangen also, das wir uns über die Option --service ersparen können. Damit können wir einfach den Namen des Service angeben, ohne die ihm zugehörigen Ressourcen kennen zu müssen.

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.

Im oben aufgeführten Report für den Service „AWS IAM“ erhalten wir so Aufschluss über sämtliche Terraform-Ressourcen. Von Access Keys und Gruppen bis hin zu Ergänzungen, Policies und Rollen können wir so in einem Zug dutzende Ressourcen abdecken.

Jetzt starten mit Drift-Management in Snyk IaC

Ganz gleich, ob Sie Infrastructure as Code gerade erst in Ihre Dev-Workflows einbinden oder bereits eine umfassende Methodik hierfür etabliert haben: Snyk IaC gibt Ihnen Features für Drift-Management an die Hand, die Ihnen Klarheit über die tatsächliche Konfiguration der Ressourcen in Ihren Cloud-Accounts vermitteln und dabei nur ein Mindestmaß an Zugriffsrechten erfordern. So können Sie Fixings schnell einsteuern und profitieren zugleich von optimaler Sicherheit für Ihre Ressourcen.

Drift-Management mit Snyk IaC ist lokal über die CLI ausführbar, lässt sich in CI/CD-Pipelines integrieren oder auch in Form per Cron-Operation als regelmäßiger Check umsetzen (ab Version 1.918.0).

Verfügbar ist Drift-Management bereits in unserer kostenlosen Produktvariante – starten Sie also noch heute mit Snyk und machen Sie Ihre Infrastruktur sicher.