Mehr IaC-Abdeckung, weniger Infrastruktur-Drift

Um Sicherheit für die Ressourcen in ihren Cloud-Umgebungen gewährleisten zu können, benötigen Entwickler in erster Linie lückenlose Visibility für diese. Infrastructure as Code macht es hierbei möglich, Cloud-Infrastrukturen zu automatisieren. So behalten Entwickler nicht nur die Kontrolle darüber, welche Ressourcen in der Cloud ausgeführt werden, sondern können auch Audits für diese Deployments einfacher umsetzen. Das Problem nur: Eine lückenlose IaC-Abdeckung für ausnahmslos alle Ressourcen ist nicht ganz so einfach zu erreichen.

Sicherheit ist immer eine Frage dessen, wie sicher in der Cloud ausgeführte Deployments sind. Nur treten bei diesen eben auch in allzu häufiger Regelmäßigkeit manuelle Änderungen auf – dies etwa durch Entwickler unterschiedlicher Teams oder auch durch authentifizierte Services. Diese Änderungen spiegeln sich in der IaC-Konfiguration nicht wider und werden entsprechend auch nicht von Audits abdeckt, was wiederum mit Problemen wie Fehlkonfigurationen und Sicherheitsrisiken einhergeht. Genau deshalb braucht es Drift-Management als Methodik, die Ressourcen aufdeckt, die sich noch nicht unter IaC-Kontrolle befinden oder deren Konfigurationen aus Gründen wie den zuvor genannten Abweichungen aufweisen.

In diesem Artikel zeigen wir auf, wie Entwickler dies mit Snyk IaC umsetzen – für nicht via IaC kontrollierte bzw. nicht verwaltete Ressourcen ebenso wie für solche, deren Konfiguration infolge von Drift von der ursprünglichen Definition abweicht.

Einrichtung der Umgebung

Mit Snyk IaC lassen sich erkannte Ressourcen in einer Listenansicht als Terraform-Ressourcen darstellen, aus der leicht zu entnehmen ist, welchen Teil des Cloud-Services die Erkennung betrifft. Ein einzelner Amazon API Gateway v2-Service beispielsweise setzt sich aus mindestens 12 Terraform-Ressourcen zusammen. Anhand der Scan-Informationen von Snyk können Sie direkt entscheiden, ob Sie die Änderung rückgängig machen, als neue Ressource importieren oder löschen möchten.

Nachvollziehen können Sie dies über die nachfolgend aufgeführte Terraform-Datei. Über diese richten wir zwei AWS-Ressourcen ein, mit denen wir im Rahmen dieses Walkthroughs arbeiten. Erstellt wird damit ein IAM-Benutzer namens „user1“ mit einem zufällig generierten Suffix, ein Access Key sowie eine Policy für auf Lesevorgänge beschränkten Zugriff.

Für diesen Walkthrough haben wir Version 1.1.7 von Terraform sowie den AWS-Provider 3.74.2 genutzt.

Verwenden Sie die folgende HCL-Konfiguration:

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 die Konfiguration wie folgt an:

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

Wichtig ist hier, dass terraform.tfstate im Root des Verzeichnisses vorhanden ist.

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

Außerdem muss der IAM-Benutzer auf AWS erfolgreich erstellt worden sein.

Vorbereitung der Umgebung

Zunächst verwenden wir nachfolgenden Befehl, um eine Liste sämtlicher Cloud-Ressourcen zu erhalten, die nicht von Terraform verwaltet werden.

1$ snyk iac describe --only-unmanaged

Womöglich werden Sie überrascht sein, wie lang die Liste entsprechender Ressourcen ist. Ganz allgemein sind dies durchaus nützliche Informationen, doch für unser Beispiel ist eine solche Menge an Ressourcen nicht zielführend. Snyk IaC gibt Ihnen ein Feature an die Hand, mit dem Sie sämtliche erkannten Ressourcen ignorieren können, indem Sie diese in einer Policy-Date mit der Endung .snyk ablegen.

Anhand des nachfolgenden Befehls ignorieren Sie diese Ressourcen also allesamt. So können Sie in einer kontrollierten Umgebung arbeiten, die lediglich die beiden zu Anfang erstellten Ressourcen beinhaltet.

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

Über einen erneuten Scan vergewissern Sie sich, dass in der Umgebung nun alle erkannten Ressourcen ignoriert werden. (Um ihren Import können Sie sich später noch ganz in Ruhe kümmern.) 

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

Damit ist unsere Umgebung nun aufgeräumt und startklar für unser Beispiel.

Ein kurzer Drift mit IAM

Wir simulieren nun drei Drift-Szenarien, die in der Praxis häufig anzutreffen sind:

1. Modifizierung eines bestehenden IAM-Benutzers – diese wollen wir rückgängig machen.

2. Manuelle Einrichtung einer neuen IAM-Policy – diese wollen wir entfernen.

3. Neu eingerichteter IAM-Benutzer – die ihm zugehörige Konfiguration wollen wir optimieren.

Rufen Sie hierzu die AWS-Konsole für IAM auf.

Bestehenden IAM-Benutzer durch zusätzlichen Tag modifizieren

1. Öffnen Sie die Seite für IAM-Benutzer und klicken Sie auf „user1“.

2. Klicken Sie auf den Tab Tags.

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

4. Fügen Sie einen neuen Schlüssel namens „environment“ sowie einen neuen Wert mit dem Namen „production“ hinzu.

5. Klicken Sie auf Save.

Starke Policy für bestehenden IAM-Benutzer einrichten

1. Öffnen Sie die Seite für IAM-Benutzer und klicken Sie 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. Validieren Sie die Policy durch Klicken auf Add permissions.

Zusätzlichen IAM-Benutzer manuell erstellen

1. Öffnen Sie die Seite für IAM-Benutzer und klicken Sie auf die Schaltfläche Add Users.

2. Im Feld User name: geben Sie „user2“ ein.

3. Wählen Sie Access key aus.

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

5. Definieren Sie hier keinerlei Berechtigungen oder Tags.

6. Klicken Sie auf Create user. Für unser Beispiel sind die dort angegeben Anmeldeinformationen nicht relevant, daher können Sie sie ignorieren.

In unsere Konfiguration haben wir damit drei manuelle Abweichungen eingebaut. Wir sind also startklar zur Drift-Erkennung mit Snyk IaC!

Drift verwalteter und nicht verwalteter Infrastruktur

Zunächst sehen wir uns an, wie Snyk IaC erkannte Änderungen darstellt. Hierzu beginnen wir mit den Ressourcen, die 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

Der Scan liefert uns folgende Ergebnisse, dies in der klassischen, von Terraform verwendeten Terminologie:

• den manuell erstellten Benutzer namens „user2“ einschließlich dem ihm zugehörigen IAM Access Key.

• die manuell für den von Terraform verwalteten IAM-Benutzer „user1“ eingerichtete IAM-Policy.

Nachfolgend führen wir nun einen Scan durch, bei dem wir nur auf die von Terraform verwalteten Ressourcen abzielen, die innerhalb der verschiedenen Terraform-States vorhanden sind:

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

Wie wir sehen, erhalten wir nun ein vollkommen anderes Ergebnis. Auch dauerte der Scan mit 36 Sekunden deutlich länger – für den Scan auf nicht verwaltete Ressourcen wurden gerade einmal 6 Sekunden benötigt.

Entnehmen können wir dem Ergebnis, dass dem IAM-Benutzer namens „user1-84i30k“, der in der HCL-Konfiguration unter dem Namen „user1“ als Ressource definiert ist, ein Tag namens „environment“ mit dem Attribut „production“ hinzugefügt wurde.

Aktionsplan

Über den Scan zur Drift-Erkennung konnten wir vier Elemente aufdecken, deren Konfiguration vom gewünschten Status abweicht. Für dieses Beispiel nehmen wir an, dass in unserem Team beschlossen wurde, wie folgt damit zu verfahren:

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

• Um die Sicherheit zu stärken, soll der IAM Access Key für „user2“ rotiert, also durchgewechselt werden.

• „user1“ darf unter keinen Umständen über Administratorrechte verfügen.

• Aufgrund spezifischer Anforderungen muss der neue Tag für „user1“ beibehalten und in Terraform importiert werden.

Deployment-Pipelines: Kein Ersatz für Mitigierung

Wir haben eine Deployment-Pipeline in Terraform aufgezogen, mit der wir nun gut aufgestellt sind. Entsprechend sollte also anzunehmen sein, dass bei Ausführung von terraform apply alles wieder in den gewünschten Zustand versetzt wird.

Tatsächlich aber bewirkt dies nur, dass Terraform ein Deployment durchführt:

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 ist überhaupt nicht darauf ausgelegt, manuell erstellte oder hinzugefügte Ressourcen zu erkennen. Entsprechend stellt das Tool für alle Änderungen lediglich den ursprünglichen Status wieder her – was hier nicht dem entspricht, was wir eigentlich erreichen wollen.

Für keines der Szenarien liefert Terraform ein zufriedenstellendes Ergebnis:

• Der manuell erstellte IAM-Benutzer und der ihm zugehörige Access Key werden nicht erkannt. (Nicht hilfreich)

• Die einem Benutzer manuell hinzugefügte Administrator-Policy wird nicht erkannt. (Nicht hilfreich)

• Der wichtige Tag, der einem verwalteten Benutzer hinzugefügt wurde, wird entfernt. (Hinterlässt Sicherheitsrisiko)

Um diese Arten von Änderungen erkennen und adäquat auf sie reagieren zu können, braucht es daher ein anderes Tool.

Abdeckung erhöhen

Wie wir sehen, haben wir zu Anfang eine Abdeckung nicht verwalteter Ressourcen 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

Starten wir also direkt und erhöhen die Abdeckung gemäß den Vorgaben unseres Teams.

Löschen der IAM-Policy für „user1“

Zunächst machen wir uns daran, die „administrator“-Policy für den verwalteten IAM-Benutzer „user1“ zu löschen. Dieser Punkt ist am drängendsten, lässt sich aber auch am einfachsten beheben:

• Rufen Sie IAM > Users > „user1“ auf.

• Klicken Sie auf Permissions und 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

Dadurch konnten wir die Abdeckung unserer AWS-Ressourcen nun von 50 % auf 60 % erhöhen.

Wir machen also direkt weiter.

Blockierung der Terraform Deployment-Pipeline aufheben

Die manuelle Änderung an den Tags für „aws_iam_user.user1“ hat eine Blockierung der Pipeline zur Folge. So werden die Tags im Falle eines Deployments auf den Zustand zurückgesetzt, der in der HCL-Konfiguration definiert ist. Lösen können wir dies, indem wir die Terraform-Konfiguration gemäß den Ergebnissen des Drift-Scans von Snyk IaC anpassen.

Dieser liefert uns folgende Informationen:

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

Daraus können wir Folgendes ablesen:

• Für uns relevant ist die Ressource aws_iam_user, die als „user1“ benannt wurde.

• Abgelegt ist die Ressource in terraform.tfstate. (Gerade in Umgebungen mit hunderten States ist dies ein äußerst nützliches Detail.)

• Es wurde ein neuer Tag-Schlüssel namens environment mit dem Wert „production“ hinzugefügt.

Entsprechend ergänzen wir die Ressource zum IAM-Benutzer einfach um den Wert environment = "production". Dies stellt sich wie folgt dar:

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}

So können wir nun auch die Blockierung der Terraform Deployment-Pipeline aufheben:

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

Die Drifts für verwaltete Ressourcen sind damit behoben, wie im nachfolgenden Screenshot zu sehen:

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

Bleibt uns noch der Punkt mit „user2“. Unser Ziel hier:

• den Benutzer in Terraform importieren

• den Schlüssel rotieren

Im ersten Schritt importieren wir hier den IAM-Schlüssel in Terraform. Am einfachsten gehen wir dabei wie folgt vor:

Zunächst ziehen wir uns aus Snyk IaC die Details zum Benutzer:

Wie wir für den Import einer aws_iam_user-Ressource vorgehen müssen, entnehmen wir der offiziellen Terraform-Dokumentation. Dort ist zu lesen: Der Import von IAM-Benutzern erfolgt über den Namen, z. B.$ terraform import aws_iam_user.lb loadbalancer.

Den Angaben zufolge ist zudem lediglich der Name als Argument erforderlich. Wir können also folgende Grundstruktur in unserer HCL-Datei verwenden:

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

Entsprechend importieren wir den Benutzer 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!

Wo wir dadurch in Sachen Abdeckung stehen, wollen wir uns natürlich auch ansehen:

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

80 %. Also nochmal 20 % mehr Abdeckung als zuvor. Und es fehlt nur noch eine Ressource!

den Schlüssel rotieren

Unser Plan ist hier, den Schlüssel beim Import in Terraform zu rotieren. Hierzu fügen wir zunächst einen neuen Schlüssel in der HCL-Konfiguration hinzu (etwa zum Zuweisen an das relevante Team) und entfernen dann den ursprünglichen Schlüssel, der noch in AWS hinterlegt ist.

Wie wir aus der Dokumentation zu Terraform für die Ressource aws_iam_access_key entnehmen, müssen wir dazu lediglich eine Ressource mit dem Namen „user2“ als Argument erstellen:

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

Die Blockierung der Deployment-Pipeline ist bereits aufgehoben, also können wir nach dieser Struktur direkt einen neuen Schlüssel via Terraform 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.

Im letzten Akt entfernen wir nun den ursprünglichen Schlüssel. Aus dem Scan von Snyk IaC erhalten wir dazu Details zum Namen des Schlüssels, der AKIASBXWQ3AYQETE6OFR lautet.

Am einfachsten lässt sich der Schlüssel dann wie folgt entfernen:

• IAM > Users > user2 > Security Credentials aufrufen

• Aus Snyk IaC den Namen des Schlüssels – AKIASBXWQ3AYQETE6OFR – entnehmen, den Schlüssel deaktivieren und anschließend löschen

Nun noch ein Blick auf die Abdeckung:

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

Perfekt! Alles ist nun wieder unter Kontrolle, umgesetzt mit Drift-Erkennung via Snyk IaC als Rückgrat.

Fazit

Wie dieser Walkthrough zur Drift-Erkennung mit Snyk IaC deutlich macht, lassen sich Konfigurationsabweichungen infolge manuell erstellter AWS-Ressourcen mit dem Toolset effektiv ausmachen. Und da es die passenden Informationen allesamt entwicklerfreundlich in Terraform-Terminologie aufbereitet, erfolgt auch der Import in Terraform-HCL-Code mühelos. Eine wichtige Erkenntnis ist außerdem, dass sich durch automatisches Zurücksetzen von Konfigurationsänderungen nicht immer der gewünschte Effekt einstellt. Vielmehr braucht es bei dieser Art von Deployment-Pipeline zusätzlich ein unkompliziertes Alerting-System.

Für uns ist bei alldem klar, wie wichtig es ist, ausnahmslos alle Infrastruktur-Elemente mittels Code zu definieren. Denn erst so wird es möglich, Entwicklern lückenlose Visibility für Problemstellen in der Infrastruktur zu liefern und ihnen schnell Security-Feedback zu geben.

Snyk IaC macht es ihnen dabei einfach, sämtliche in ihrem AWS-Account ausgeführten Ressourcen in Terraform-Code zu integrieren, so die IaC-Abdeckung insgesamt zu erhöhen und dabei Sicherheitsrisiken zu minimieren. Entscheidend ist hier der lückenlose Feedback-Loop, den Snyk IaC zwischen den Teams aus Cloud-Security und Entwicklung möglich macht, sowie Fixing-Empfehlungen in einem Format, das für Dev-Teams intuitiv umsetzbar ist.