Benutzerdefinierte IaC-Regeln mit Snyk entwickeln

In einer zunehmend cloudnativen Welt ist Infrastructure as Code (IaC) oft der erste Berührungspunkt mit einer Anwendung. Und da Technologien wie Kubernetes und Terraform immer beliebter werden, aktualisieren die meisten App-Entwickler im Laufe ihrer Karriere mindestens einmal eine Kubernetes- oder Terraform-Ressource.

Die Aktualisierung und Wartung der Infrastruktur kann so einfach sein wie die Verwaltung einiger Konfigurationsdateien oder so komplex wie die Orchestrierung einer komplexen Architektur mit mehreren cloudnativen Stacks. Eines gilt jedoch immer: Infrastruktursicherheit ist entscheidend für die Anwendungssicherheit. Obwohl viele Cloud-Anbieter und IaC-Scan-Tools integrierte oder von der Community beigesteuerte Konfigurations- und Sicherheitsregelsätze bieten, ist die Infrastruktur oft zu vielfältig und zu komplex für einen Ansatz nach dem Motto „eine Lösung für alles“.

In diesem Artikel zeige ich Ihnen, wie Sie Ihre Infrastrukturumgebung mit benutzerdefinierten Regeln für Snyk IaC absichern. Mit dem SDK für Snyk-IaC-Regeln (snyk-iac-rules) können Sie jetzt benutzerdefinierte Infrastrukturregeln für die Snyk CLI schreiben, testen und bündeln.

Mehr Flexibilität mit Open Policy Agent (OPA)

Im Hintergrund nutzt Snyk IaC Open Policy Agent (OPA), einen universellen Open-Source-Richtlinienagenten, und dessen Sprache Rego, um benutzerdefinierte Regeln zu definieren. Als frameworkunabhängiger Agent erleichtert OPA Teams die Anpassung und Durchsetzung von Richtlinien für ihren gesamten cloudnativen Stack – ob für Infrastruktur, Anwendungsautorisierung oder die Zulassungssteuerung in Kubernetes.

Da die Regeln in der nativen Abfragesprache von OPA geschrieben werden, lassen sie sich auch exportieren und außerhalb von Snyk wiederverwenden. So können Sie Ihre Investitionen hier im gesamten Integrationsökosystem von OPA nutzen.

Für die Anleitung benötigen Sie Grundkenntnisse in OPA sowie in WebAssembly (Wasm) und OCI-Artefakten, mit denen wir die Regeln bündeln und verteilen.

Besser absichern mit benutzerdefinierten Regeln

Mit benutzerdefinierten Regeln können Sie jeden konkreten Anwendungsfall berücksichtigen. In Kombination mit vorgefertigten, von Sicherheitsexperten modellierten Bedrohungsregelsätzen sind sie ein leistungsstarkes Werkzeug.

Nehmen wir als Beispiel für eine benutzerdefinierte Regel an, ich sei Security Architect und hätte eine bestimmte interne Anforderung: Alle Terraform-Ressourcen vom Typ aws_iam_role in unserer Anwendung müssen mit den Tags owner, description und type versehen sein.

Dazu möchte ich eine Regel ausführen, die:

• sicherstellt, dass alle vorhandenen und zukünftigen IAM-Rollenressourcen die Tags owner, description und type enthalten

• App-Entwickler benachrichtigt, wenn sie vergessen, Tags hinzuzufügen.

Außerdem möchte ich unsere CI/CD so konfigurieren, dass sie bei einer Codeänderung fehlschlägt, wenn diese den Standard nicht erfüllt, damit sie nicht in unseren Produktionsumgebungen landet.

Wie würde ich das umsetzen? Indem ich die Snyk CLI so konfiguriere, dass sie in meiner CI/CD mit einem benutzerdefinierten Regelsatz ausgeführt wird, den ich schreibe, bündele und an einem sicheren Ort meiner Wahl veröffentliche.

Eine benutzerdefinierte IaC-Regel mit Snyk entwickeln

Mit dem neuen SDK für Snyk-IaC-Regeln kann ich genau das tun. Ich installiere es auf meinem Rechner und kann mithilfe der Dokumentation zu benutzerdefinierten Regeln meinen neuen Tagging-Standard schnell in der Snyk CLI durchsetzen.

Nehmen Sie die folgende Terraform-Ressource als Beispiel. Sie soll unsere Tags owner, description und type enthalten:

1resource "aws_iam_role" "denied" {
2  name = "denied"
3  assume_role_policy = jsonencode({
4      Version   = "2012-10-17"
5      Statement = [
6        {
7          Action    = "sts:AssumeRole"
8          Effect    = "Allow"
9          Sid       = ""
10          Principal = {
11            Service = "ec2.amazonaws.com"
12          }
13        },
14      ]
15  })
16  tags = {
17    description = "a tag that describes something"
18  }
19}

Gemäß der Anleitung in der Dokumentation zu benutzerdefinierten Regeln führe ich den Befehl template aus, um das Grundgerüst einer Regel zu erstellen:

1$ snyk-iac-rules template --rule CUSTOM-RULE-8

Der Tagging-Standard soll als Regel mit mittlerem Schweregrad eingestuft werden. Deshalb passe ich die Vorlage entsprechend an und ändere Titel und Meldung:

1package rules
2
3aws_iam_role_tags_missing(resource) {
4    not resource.tags.owner
5}
6
7aws_iam_role_tags_missing(resource) {
8    not resource.tags.description
9}
10
11aws_iam_role_tags_missing(resource) {
12    not resource.tags.type
13}
14
15deny[msg] {
16    resource := input.resource.aws_iam_role[name]
17    aws_iam_role_tags_missing(resource)
18
19    msg := {
20        "publicId": "CUSTOM-RULE-8",
21        "title": "IAM Role missing one of the required tags: owner, description or type",
22        "severity": "medium",
23        "msg": sprintf("input.resource.aws_iam_role[%s].tags", [name]),
24        "issue": "",
25        "impact": "",
26        "remediation": "",
27        "references": [],
28    }
29}

Bevor ich die Regel bündele und veröffentliche, schreibe ich Unit-Tests, um ihr Verhalten zu überprüfen, und lege meine beispielhafte Terraform-Fixture-Datei in der generierten Datei ./rules/CUSTOM-RULE-8/fixtures/denied2.tf ab:

1package rules
2
3import data.lib
4import data.lib.testing
5
6test_CUSTOM_RULE_8 {
7        # array containing test cases where the rule is allowed
8        allowed_test_cases := []
9
10        # array containing cases where the rule is denied
11        denied_test_cases := [{
12            "want_msgs": ["input.resource.aws_iam_role[denied].tags"],
13            "fixture": "denied2.tf",
14        }]
15
16        test_cases := array.concat(allowed_test_cases, denied_test_cases)
17        testing.evaluate_test_cases("CUSTOM-RULE-8", "./rules/CUSTOM-RULE-8/fixtures", test_cases)
18}

Diese und weitere Regeln finden Sie in unserem öffentlichen GitHub-Repository.

1$ snyk-iac-rules test
2PASS: 1/1

Sobald ich die Tests ausgeführt habe und mit dem Ergebnis zufrieden bin, bündele ich die Regel mithilfe des SDK. Mit dem Flag --rules kann ich sie sogar lokal mit der Snyk CLI testen. Zunächst stelle ich sicher, dass ich bei einer Organisation namens test-org angemeldet bin. Von nun an führe ich alle Experimente mit meinen benutzerdefinierten Regeln dort aus:

1$ snyk auth

Anschließend erstelle ich ein Bundle meiner benutzerdefinierten Regeln und übergebe es an das Flag --rules, um sicherzustellen, dass meine IaC-Probleme erkannt werden:

1$ snyk-iac-rules build .
2Generated bundle: bundle.tar.gz
3
4$ snyk iac test --rules=bundle.tar.gz ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf
5
6Testing ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf...
7
8Infrastructure as code issues:
9  ✗ IAM Role missing one of the required tags: owner, description or type [Medium Severity] [CUSTOM-RULE-8]
10    introduced by input > resource > aws_iam_role[denied] > tags
11
12Organization:      test-org
13Type:              Terraform
14Target file:       ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf
15Project name:      fixtures
16Open source:       no
17Project path:      ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf
18
19Tested ./fixtures/custom-rules/rules/CUSTOM-RULE-8/fixtures/denied2.tf for known issues, found 1 issues

Da ich nun sicher bin, dass die Snyk CLI meine Regel interpretieren kann, übertrage ich sie in eine OCI-Registry – in diesem Fall DockerHub – und kennzeichne sie als erste Version meiner benutzerdefinierten Regeln. So kann ich bei späteren Änderungen mit möglichen inkompatiblen Anpassungen die Regeln schrittweise ausrollen, indem ich ein neues Tag verwende:

1$ snyk-iac-rules push --r docker.io/snykgoof/oci-example:v1 bundle.tar.gz

Zu guter Letzt setze ich die Verwendung meiner neuen benutzerdefinierten Regel in allen Teams meiner Abteilung durch. Dazu konfiguriere ich die IaC-Einstellungen meiner Snyk-Gruppe über die öffentliche Group IaC Settings API.

1curl --location --request PATCH 'https://api.snyk.io/v3/groups/<group_id>/settings/iac/?version=2021-11-03~beta' \
2--header 'Content-Type: application/vnd.api+json' \
3--header 'Authorization: token <API key from Snyk>' \
4--data-raw '{
5   "data": {
6         "type": "iac_settings",
7         "attributes": {
8           "custom_rules": {
9             "oci_registry_url": "https://registry-1.docker.io/snykgoof/oci-example",
10             "oci_registry_tag": "v1",
11             "is_enabled": true
12           }
13       }
14   }
15}'

Ich habe all diese Schritte mithilfe eines GitHub-Aktionsworkflows automatisiert, wie Sie in unserem öffentlichen GitHub-Repository sehen können. Ab sofort verwenden alle App-Entwickler und CI/CD-Pipelines, die bei einer Organisation innerhalb meiner Gruppe authentifiziert sind, meine benutzerdefinierte Regel. Wie Sie die Snyk CLI und das SDK für Snyk-IaC-Regeln in GitHub integrieren, erfahren Sie in unserer Dokumentation.

Wenn wir für verschiedene Unternehmensbereiche unterschiedliche benutzerdefinierte Regeln anwenden möchten, können wir die Einstellungen für benutzerdefinierte Regeln auch auf Organisationsebene überschreiben. So wird für die jeweilige Organisation ein eigener Regelsatz ausgeführt. Damit ich beispielsweise weiterhin das Flag --rules verwenden kann, um meine benutzerdefinierten Regeln mit der Snyk CLI zu testen, habe ich die Einstellungen für benutzerdefinierte Regeln in meiner Organisation test-org deaktiviert. So kann ich meine eigenen benutzerdefinierten Regeln lokal bereitstellen:

Vielleicht benötigt das Platform-Team künftig einen restriktiveren Satz benutzerdefinierter Regeln. In diesem Fall konfiguriere ich für dessen Organisation ein anderes Bundle mit benutzerdefinierten Regeln, das unter einem anderen OCI-Artefakt gespeichert ist.

Die Vorteile benutzerdefinierter Regeln für Snyk IaC nutzen

Wir haben gesehen, wie ich als Security Architect mithilfe des SDK für Snyk-IaC-Regeln neue Sicherheitsstandards für meine Abteilung konfiguriert habe. Sehen wir uns nun an, wie mir diese Funktion als App-Entwickler während der Entwicklung hilft.

Nehmen wir an, ich füge der Terraform-Infrastruktur unserer Anwendung eine neue Ressource vom Typ aws_iam_role hinzu, um eine neue IAM-Rolle zu konfigurieren:

1resource "aws_iam_role" "new_role" {
2  name               = "new_role"
3  assume_role_policy = jsonencode({
4    Version   = "2021-11-18"
5    Statement = [
6      {
7        Action    = "sts:AssumeRole"
8        Effect    = "Allow"
9        Sid       = ""
10        Principal = {
11          Service = "ec2.amazonaws.com"
12        }
13      },
14    ]
15  })
16}

Ich habe die Ressource lokal getestet und überprüft, dass meine IAM-Rolle korrekt konfiguriert ist. Allerdings habe ich vergessen, dass meine Abteilung für alle Ressourcen sehr strenge Tagging-Vorgaben hat. Als ich einen PR erstellen möchte, sehe ich, dass das Repository, in das ich meine Änderungen übertrage, für die Ausführung der Snyk IaC GitHub Action konfiguriert ist – und diese schlägt fehl.

Ich sehe mir die Ergebnisse an und stelle fest, dass meine neue Datei die PR-Prüfung fehlschlagen lässt. Genauer gesagt fehlen meiner Ressource die Tags owner, description und type.

Ich gehe zurück zu meinem Code und füge die fehlenden Tags hinzu. Sobald ich meine Änderung übertrage und die PR-Prüfung erneut ausgeführt wurde, kann ich die neue Ressource sicher und mit gutem Gewissen in unsere Produktionsumgebung übernehmen!

Ihre Anwendungen mit Snyk IaC absichern

Snyk Infrastructure as Code (Snyk IaC) hilft Ihnen, schnell und sicher zu entwickeln. Dafür stellt es Entwicklern Sicherheitsinformationen und Inline-Korrekturen für Terraform-, CloudFormation- und Kubernetes-Konfigurationen sowie ARM-Vorlagen bereit, die sich direkt in den Code übernehmen lassen.

Snyk IaC fügt sich in die Arbeitsumgebung von Entwicklern ein und lässt sich in Systeme wie Terraform Cloud und CI/CD-Tools sowie in Entwicklerwerkzeuge wie Quellcodeverwaltungssysteme (GitHub, GitLab, Bitbucket) und IDEs integrieren.

Sie können jetzt kostenlos loslegen – mit Snyk IaC auf unserer Plattform oder durch Herunterladen der neuesten Snyk CLI.