Tools zur Erkennung von Infrastruktur-Drift

Infrastruktur-Drift vorherzusagen, ist wie Schneefall im Winter vorherzusagen: Sie wissen, dass es irgendwann schneien wird, können aber nicht genau sagen, wann. Und genau wie beim Schneefall sind Sie am besten vorbereitet und Ihre Infrastruktur am sichersten, wenn Sie Drift so früh wie möglich erkennen.

In diesem Artikel sehen wir uns die Grundlagen der Drift-Erkennung, die verschiedenen Arten von Drift und ihre Ursachen sowie Tools an, mit denen Sie Drift anhand eines einfachen Beispiels erkennen können.

Was ist Drift-Erkennung?

Um zu verstehen, warum Sie Tools zur Drift-Erkennung benötigen, sollten Sie zunächst verstehen, was Infrastruktur-Drift bedeutet. Kurz gesagt: Dabei weicht Ihre gesamte Infrastruktur von Ihrer Konfigurationsdatei ab.

In diesem Blogartikel konzentrieren wir uns auf HashiCorp Terraform als Infrastructure-as-Code-Tool (IaC) zur Bereitstellung unserer Cloud-Ressourcen. In der Terraform-Welt liegt Drift – also eine Abweichung Ihrer Infrastruktur – vor, wenn sich Ihre State-Datei von dem unterscheidet, was Sie bei Ihrem Cloud-Anbieter angewendet haben.

Hier können geeignete Tools zur Erkennung solcher Abweichungen Ihre Sicherheitslage deutlich verbessern. Stellen Sie sich eine ideale Welt vor, in der Sie benachrichtigt werden, wenn jemand Ihre Security Group manuell statt mit Terraform ändert. Wäre es nicht auch großartig, Benachrichtigungen über neu erstellte Ressourcen außerhalb von Terraform zu erhalten?

Verwaltete und nicht verwaltete Ressourcen

Um meine oben beschriebene Idealvorstellung zu veranschaulichen, unterscheiden wir zwei Arten von Drift:

Drift bei von IaC verwalteten Ressourcen

Da uns die Konfigurations- und State-Dateien aller Ressourcen vorliegen, die bei Ihrem Cloud-Anbieter angewendet und bereitgestellt wurden, kann Ihr IaC-Tool Sie in der Regel gut dabei unterstützen, Änderungen zu erkennen, die außerhalb des Tools vorgenommen oder noch nicht angewendet wurden.

Drift bei nicht von IaC verwalteten Ressourcen

Diese Art von Drift ist dagegen schwer zu erkennen, da solche Ressourcen in Ihrer Konfigurations- oder State-Datei gar nicht definiert sind.

Warum entsteht Drift?

Drift kann aus vielen offensichtlichen Gründen entstehen. HashiCorp erklärt es jedoch besser als alle anderen:

„Im Kontext Ihrer Konfiguration tritt Drift auf, wenn Ressourcen hinzugefügt oder entfernt oder Ressourcendefinitionen geändert werden. Außerhalb Ihrer Konfiguration entsteht Drift, wenn Ressourcen beendet wurden oder ausgefallen sind und wenn Änderungen manuell oder über andere Automatisierungstools vorgenommen wurden.“

Sehen wir uns reale Beispiele für die beiden Drift-Arten und ihre Auswirkungen an. Bei einer verwalteten Ressource könnte jemand beispielsweise die Versionierung Ihres mit Terraform konfigurierten Amazon-S3-Buckets manuell ändern. Bei einer nicht verwalteten Ressource könnte jemand manuell einen S3-Bucket außerhalb von Terraform hinzufügen, etwa in der AWS-Konsole. (Weitere Tipps zum Umgang mit Drift durch manuelle Änderungen finden Sie in unserem vorherigen Artikel.)

Welche Tools helfen uns, solche Abweichungen zu erkennen?

Sehen wir uns nun Tools an, mit denen Sie Drift bei verwalteten und nicht verwalteten Ressourcen erkennen können. Für den Rest dieses Artikels verwenden wir dasselbe einfache Terraform-Beispiel wie oben:

1resource "aws_s3_bucket" "example" {
2        bucket = "drift-example-managed-resource"
3        versioning {
4                enabled = true
5        }
6}

Wir ändern in der Konsole lediglich das Attribut für die Versionierung zu false, um Drift zu erzeugen. Außerdem erstellen wir manuell denselben S3-Bucket in der AWS-Konsole.

Sehen wir uns nun drei Tools für das Drift-Management an:

1. terraform plan

2. CloudQuery

3. driftctl

1. terraform plan

Der Befehl terraform plan beschreibt, was angewendet werden muss, damit Ihre gewünschte Konfiguration umgesetzt wird. Sehen wir uns die Ausgabe dieses Befehls für unsere tatsächliche Infrastruktur an:

1$ terraform plan
2
3aws_s3_bucket.example: Refreshing state... [id=drift-example-managed-resource]
4
5Note: Objects have changed outside of Terraform
6
7Terraform detected the following changes made outside of Terraform since the last "terraform apply":
8
9  # aws_s3_bucket.example has changed
10  ~ resource "aws_s3_bucket" "example" {
11        id                          = "drift-example-managed-resource"
12        # (10 unchanged attributes hidden)
13
14      ~ versioning {
15          ~ enabled    = true -> false
16            # (1 unchanged attribute hidden)
17        }
18    }
19
20Unless you have made equivalent changes to your configuration, or ignored the relevant attributes using ignore_changes, the following plan may include actions to undo or respond to these changes.
21
22────────────────────────────────────────────────────────────
23Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
24  ~ update in-place
25
26Terraform will perform the following actions:
27
28  # aws_s3_bucket.example will be updated in-place
29  ~ resource "aws_s3_bucket" "example" {
30        id                          = "drift-example-managed-resource"
31        # (10 unchanged attributes hidden)
32
33      ~ versioning {
34          ~ enabled    = false -> true
35            # (1 unchanged attribute hidden)
36        }
37    }
38
39Plan: 0 to add, 1 to change, 0 to destroy.
40
41────────────────────────────────────────────────────────────
42
43Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly these actions if you run "terraform apply" now.

Terraform meldet, dass es Drift bei der verwalteten Ressource festgestellt hat, und erklärt, worin die Änderung besteht (z. B. Versionierung von true zu false). Anschließend gibt Terraform aus, was bei einer Anwendung des Plans geschehen würde (z. B. Versionierung zurück zu true).

Vorteile:

• Zuverlässige Erkennung von Drift bei verwalteten Ressourcen

• Unterstützt alle Terraform-Ressourcen

Nachteile:

• Drift bei nicht verwalteten Ressourcen lässt sich nicht erkennen

• Pläne für mehrere State-Dateien werden nicht unterstützt

2. CloudQuery

CloudQuery ist ein Open-Source-Cloud-Asset-Inventar, das auf SQL basiert. Standardmäßig werden alle Ressourcen der gewünschten Cloud-Anbieter abgerufen, formatiert und in PostgreSQL geladen. Darauf baut CloudQuery einen Befehl zur Drift-Erkennung auf, um „dieses Drift-Problem in ein Datenproblem zu verwandeln“, wie das Unternehmen sagt.

Sobald die CloudQuery-CLI installiert ist, können wir wieder die Drift bei unseren S3-Buckets untersuchen.

1$ cloudquery fetch
2
3Initializing CloudQuery Providers...
4
5✓ cq-provider-aws@v0.10.10 verified    0s  100 %
6
7Finished provider initialization...
8
9Upgrading CloudQuery providers aws
10
11✓ Upgraded provider aws to latest successfully.
12
13Finished upgrading providers...
14
15Starting provider fetch...
16
17✓ cq-provider-aws@latest fetch complete   15s   Finished Resources: 129/129
18
19Provider fetch complete.
20
21Provider aws fetch summary: ✓ Total Resources fetched: 523 ⚠️ Warnings: 0 ❌ Errors: 0

Wie oben beschrieben, ruft der erste Befehl alle Ressourcen unserer Cloud-Anbieter ab und speichert sie in einer PostgreSQL-Tabelle.

1$ cloudquery drift scan --deep --debug terraform.tfstate
2
3Initializing CloudQuery Providers...
4
5⌛cq-provider-aws@v0.10.11 downloading...                           4s  100 %
6
7Finished provider initialization...
8
9Using profile drift-example
10Starting module...
11DIFF RESOURCE: s3.buckets:drift-example-managed-resource
12+------------------------------------------+-----------+---------------+-------------------------+
13|                 AWS EXPR                 |  AWS VAL  | TERRAFORM VAL |     TERRAFORM EXPR      |
14+------------------------------------------+-----------+---------------+-------------------------+
15| COALESCE("c"."versioning_status",'')     | Suspended | <nil>         | versioning_status       |
16| COALESCE("c"."versioning_mfa_delete",'') | Disabled  | <nil>         | versioning_mfa_delete   |
17| "c"."block_public_acls"                  | true      | <nil>         | block_public_acls       |
18| "c"."block_public_policy"                | true      | <nil>         | block_public_policy     |
19| "c"."ignore_public_acls"                 | true      | <nil>         | ignore_public_acls      |
20| "c"."restrict_public_buckets"            | true      | <nil>         | restrict_public_buckets |
21+------------------------------------------+-----------+---------------+-------------------------+
22Matching attributes "region", "logging_target_prefix", "logging_target_bucket", "policy", "tags", "replication_role", "arn", "ownership_controls"
23+-----------------------+---------------------------------------------------------+
24|       ATTRIBUTE       |                     MATCHING VALUE                      |
25+-----------------------+---------------------------------------------------------+
26| region                | us-west-2                                               |
27| logging_target_prefix |                                                         |
28| logging_target_bucket |                                                         |
29| policy                | <nil>                                                   |
30| replication_role      |                                                         |
31| arn                   | arn:aws:s3:::drift-example-managed-resource             |
32| ownership_controls    | <nil>                                                   |
33+-----------------------+---------------------------------------------------------+
34Module output:
35=== DRIFT RESULTS  ===
361 Resources not managed by Terraform
37  aws:s3.buckets:
38    - drift-example-un-managed-resource
391 Resources managed by Terraform but drifted
40  aws:s3.buckets:
41    - drift-example-managed-resource
42=== SUMMARY ===
43Total number of resources: 2
44 - 1 not managed by Terraform
45 - 1 managed by Terraform but drifted
46 - 50% covered by Terraform
47Finished module

Diese Ausgabe ist interessant: Es wurden beide S3-Buckets gefunden, ein verwalteter und ein nicht verwalteter. Außerdem wurde festgestellt, dass bei meinem verwalteten Bucket Drift vorliegt. Die Analyse ist jedoch etwas seltsam, denn laut AWS ist der S3-Bucket nicht versioniert, während der Status in meiner State-Datei als unbekannt angegeben wird. Wahrscheinlich liegt ein Fehler darin, wie Terraform-Attribute ausgewertet werden. Die anderen Attribute mit Drift lassen mich fragen, was passieren würde, wenn ich einen verwalteten Bucket ohne Drift hätte.

Ich habe die ursprüngliche Bucket-Konfiguration mit terraform apply erneut angewendet und anschließend cloudquery fetch sowie cloudquery drift scan --deep --debug terraform.tfstate erneut ausgeführt:

1$ terraform plan
2
3aws_s3_bucket.example: Refreshing state... [id=drift-example-managed-resource]
4
5No changes. Your infrastructure matches the configuration.
6
7Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
8
9$ cloudquery drift scan --deep --debug terraform.tfstate
10
11...
12
13DIFF RESOURCE: s3.buckets:drift-example-managed-resource
14+------------------------------------------+----------+---------------+-------------------------+
15|                 AWS EXPR                 | AWS VAL  | TERRAFORM VAL |     TERRAFORM EXPR      |
16+------------------------------------------+----------+---------------+-------------------------+
17| COALESCE("c"."versioning_status",'')     | Enabled  | <nil>         | versioning_status       |
18| COALESCE("c"."versioning_mfa_delete",'') | Disabled | <nil>         | versioning_mfa_delete   |
19| "c"."block_public_acls"                  | true     | <nil>         | block_public_acls       |
20| "c"."block_public_policy"                | true     | <nil>         | block_public_policy     |
21| "c"."ignore_public_acls"                 | true     | <nil>         | ignore_public_acls      |
22| "c"."restrict_public_buckets"            | true     | <nil>         | restrict_public_buckets |
23+------------------------------------------+----------+---------------+-------------------------+
24…

CloudQuery stellte weiterhin Drift bei meinem Bucket fest und änderte dabei in seiner Datentabelle den Status der Versionierung. Das ist eindeutig ein falsch positives Ergebnis, das nicht berücksichtigt werden sollte, da die Versionierung meines Buckets in der AWS-Konsole aktiviert ist.

Vorteile:

• Sehr schnelles Auflisten meiner Cloud-Ressourcen mit dem fetch-Befehl

• Nicht verwaltete Ressourcen werden mit dem einfachen Befehl drift scan erkannt

• Unterstützt das Scannen mehrerer State-Dateien

Nachteile:

• Unzuverlässige Ausgabe zu Attributen mit Drift bei S3-Buckets mit dem Befehl drift scan --deep --debug

• Unterstützt nur wenige Backends zum Speichern von State-Dateien (z. B. S3 und lokal)

• Unterstützt nicht alle Terraform-Ressourcen

• Erfordert eine SQL-Datenbank

3. driftctl

driftctl ist ein kostenloses Open-Source-CLI-Tool, das vor Infrastruktur-Drift warnt. Es hilft dabei, Drift bei verwalteten und nicht verwalteten Ressourcen zu erkennen, nachzuverfolgen und entsprechende Benachrichtigungen auszugeben. Testen wir es anhand unseres Beispiels. Hinweis: driftctl ist Snyks eigene Open-Source-Engine zur Drift-Erkennung.

1$ driftctl scan --deep
2
3Scanned states (1)
4Found resources not covered by IaC:
5  aws_s3_bucket:
6    - drift-example-un-managed-resource
7Found changed resources:
8  From tfstate://terraform.tfstate
9    - drift-example-managed-resource (aws_s3_bucket.example):
10        ~ versioning.0.enabled: true => false
11Found 2 resource(s)
12 - 50% coverage
13 - 1 resource(s) managed by Terraform
14     - 1/1 resource(s) out of sync with Terraform state
15 - 1 resource(s) not managed by Terraform
16 - 0 resource(s) found in a Terraform state but missing on the cloud provider
17Scan duration: 17s
18Provider version used to scan: 3.74.3. Use --tf-provider-version to use another version.

Diese Ausgabe zeigt, dass driftctl unsere beiden Ressourcen gefunden hat. Bei der verwalteten Ressource wurde ein Attribut mit Drift festgestellt: der Status der Versionierung. Bei der anderen Ressource handelt es sich um unseren nicht verwalteten S3-Bucket.

Vorteile:

• Attribute mit Drift bei verwalteten Ressourcen werden mit dem driftctl scan --deep command erkannt

• Drift bei nicht verwalteten Ressourcen wird mit dem driftctl scan command erkannt

• Unterstützt das Scannen mehrerer State-Dateien

Nachteile:

• Scans im Modus --deep können sehr lange dauern, da alle Ressourcen eines Kontos aufgelistet und für jede Ressource Details abgerufen werden

• Beim Scannen kann es zu API-Drosselungsfehlern kommen, da für das Abrufen aller Informationen intensiv auf die API des Cloud-Anbieters zugegriffen wird

• Unterstützt nicht alle Terraform-Ressourcen

Was Sie bei Drift-Tools beachten sollten

Alle drei Tools leisten gute Arbeit. Fassen wir zusammen, worin ihre besonderen Stärken liegen.

Der Befehl terraform plan ist ein sehr leistungsstarkes Tool, das Sie in einer regelmäßig ausgeführten Pipeline für all Ihre State-Dateien einsetzen können. So profitieren Sie nicht nur davon, dass das Tool alle Ressourcen abdeckt, sondern erhalten auch eine einheitliche und gut lesbare Darstellung von Attributen mit Drift. Der einzige Nachteil ist, dass Sie Ihre State-Dateien nicht zusammenführen und den Befehl nicht an einem zentralen Ort ausführen können, um nach Ressourcen mit Drift zu suchen. Nicht verwaltete Ressourcen zu melden, gehört zwar nicht zu den Aufgaben des Tools, ist aber dennoch eine wesentliche Funktion.

Die Ergebnisse des CloudQuery-Befehlszeilentools sind gemischt. Einerseits ist der Auflistungsbefehl (fetch) eine beeindruckende Technologie. Sie erhalten damit kostenlos eine Open-Source-Alternative, die Ihnen mithilfe von SQL als Abfrage- und Richtlinien-Engine umfassende Einblicke in Ihre Cloud-Infrastruktur ermöglicht. Andererseits ist der Befehl zur Drift-Erkennung recht eingeschränkt. Meine Tests zeigen, dass Sie sich bei der Erkennung von Drift bei verwalteten Ressourcen nicht darauf verlassen können. Außerdem eignet sich das Tool zur Erkennung nicht verwalteter Ressourcen nur in einfachen Szenarien: Sie müssen lokal (meist zum Testen des Tools) oder über einen S3-Bucket (Best Practice für Tests in einer CI-Pipeline) auf Ihre State-Datei zugreifen können. Der Befehl zur Drift-Erkennung befindet sich glücklicherweise noch in der Alpha-Phase. Ich bin gespannt, wie sich dieses CLI-Tool weiterentwickelt.

Wenn driftctl in Ihre CI integriert ist und täglich ausgeführt wird, können Sie Drift bei verwalteten und nicht verwalteten Ressourcen kontinuierlich überwachen und sich darüber benachrichtigen lassen. Dank der großen Auswahl unterstützter Backends zum Speichern von State-Dateien eignet sich das Tool für die meisten Infrastrukturen. Wie bei CloudQuery können Sie außerdem Ressourcen herausfiltern oder ignorieren, die für Sie nicht relevant sind, und so einen passenden Bericht erstellen. Eine ernsthafte Schwäche des Designs von driftctl ist, dass sehr große Infrastrukturen aufgrund von API-Drosselungen möglicherweise nicht reibungslos gescannt werden können. Auch die Ausführungszeit im Modus --deep kann beim lokalen Testen großer Infrastrukturen störend lang sein; in einer CI-Pipeline ist das weniger problematisch.

Zu guter Letzt: Berechtigungen. driftctl und CloudQuery benötigen für ihre Arbeit keinen Terraform-Code, sondern lediglich Ihre State-Datei. Das macht den Einsatz einfacher. Beide folgen dem Best Practice, Berechtigungen nach dem Prinzip der geringsten Privilegien zu vergeben, um Ihren gesamten Cloud-Anbieter zu scannen. Sie benötigen daher für beide Befehle nur eine Richtlinie mit Leseberechtigung. Beim Terraform-Befehl ist das natürlich anders: Er benötigt Lese- und Schreibberechtigungen, um Ihre Infrastruktur zu erstellen, zu aktualisieren oder zu löschen, und muss Ihren Code lesen, um zu wissen, was bereitgestellt oder entfernt werden soll.

Wie es mit Snyk IaC weitergeht

Wenn Sie nicht verwaltete Ressourcen ebenfalls unter IaC-Kontrolle bringen und Drift bei Ihren verwalteten Ressourcen erkennen möchten, bietet Snyk genau dafür eine Lösung. Das Drift-Management in Snyk IaC hilft Ihnen, Ihre Infrastruktur schneller abzusichern, indem es Entwicklerinnen und Entwicklern Probleme und passende Korrekturen direkt und in verständlicher Sprache meldet. Durch schnellere Feedback-Schleifen zwischen Cloud-Security- und Entwicklungsteams können Entwicklerinnen und Entwickler die Verantwortung für ihr Terraform übernehmen – vom Code bis zur Cloud – und Infrastrukturkonfigurationen auch nach der Bereitstellung absichern. Darüber hinaus macht die Lösung nicht verwaltete Ressourcen in Cloud-Umgebungen sichtbar, sodass Sie sie unter IaC-Kontrolle bringen und das Drift-Risiko von Anfang an senken können.

Weitere Ressourcen zum Drift-Management

Wenn Sie mehr über Drift-Management in Verbindung mit Terraform erfahren möchten, finden Sie in unserem Blog weitere Artikel:

• Mehrere Terraform-Versionen verwalten

• Mehrere Terraform-Umgebungen verwalten

• Bestehende Infrastruktur in Terraform importieren

• Konfigurations-Drift erkennen und verhindern