Terraform-IaC-Sicherheit in CI/CD mit Regula und Bitbucket Pipelines prüfen [Tutorial]

Regula 2.3.0 ermöglicht Cloud-Teams, Terraform-, CloudFormation-, Azure-Resource-Manager- und Kubernetes-Infrastruktur als Code (IaC) vor der Bereitstellung auf Sicherheits- und Compliance-Verstöße zu prüfen. Durch die Integration von Regula in CI/CD-Pipelines (Continuous Integration/Continuous Delivery) lässt sich die sichere Bereitstellung von Cloud-Infrastruktur zusätzlich automatisieren.

In diesem Blogbeitrag zeigen wir, wie Sie Regula mit Bitbucket Pipelines (einem in Bitbucket integrierten CI/CD-Dienst) für automatisierte Tests von in Terraform deklarierten Amazon-Web-Services-Ressourcen (AWS) verbinden. Wenn wir Änderungen in unser Terraform-Repository übernehmen, lösen wir mit Bitbucket Pipelines einen Build aus. Wir zeigen, wie Regula eine Sicherheitslücke erkennt und den CI-Build fehlschlagen lässt – und wie Sie den Verstoß beheben, damit der Build erfolgreich ist.

Am Ende führt die CI/CD-Pipeline die folgenden Schritte aus:

1. Sie übernehmen IaC in einen Branch (in diesem Beispiel der Einfachheit halber in den Main-Branch; das lässt sich aber auch für Pull Requests umsetzen und anpassen).

2. Sie pushen die Commits und lösen damit einen Build in Bitbucket Pipelines aus.

3. Bitbucket Pipelines führt Regula für Ihr Repository aus (in diesem Beispiel haben wir außerdem Terraform-Formatierungs- und Validierungsprüfungen ergänzt, um Best Practices zu veranschaulichen).

4. Besteht die IaC in Ihrem Repository alle Regula-Prüfungen, ist der Build in Bitbucket Pipelines erfolgreich. Andernfalls schlägt er fehl.

Tipp: Auch wenn sich CI/CD-Tools voneinander unterscheiden, können Sie die oben beschriebenen Schritte befolgen, um Ihre IaC mit Regula in CI/CD zu prüfen.

Voraussetzungen

Für die folgenden Schritte benötigen Sie:

• Ein Bitbucket-Konto (entweder ein Bitbucket-Cloud- oder ein Bitbucket-Server-Konto)

• Aktivierte Multi-Faktor-Authentifizierung für Ihr Bitbucket-Konto

• Ein Cloud-Provider-Konto und Zugangsdaten, die in Bitbucket als Repository-Variablen hinterlegt sind (für diese Demonstration verwenden wir AWS)

• Ein Bitbucket-Repository (lokal geklont) mit Cloud-Ressourcen, die mit Terraform deklariert wurden (weiter unten sehen Sie den Aufbau meines Repositorys)

Was steckt im Repository?

Oben sehen Sie die Dateistruktur des Repositorys. Besonders wichtig sind:

• main.tf: Eine Terraform-Datei mit Provider- und Kontoinformationen

• ec2/instance.tf: Eine Terraform-Datei mit einer absichtlich eingefügten Sicherheitslücke

• .regula.yaml: Eine Regula-Konfigurationsdatei, in der festgelegt wird, wie Regula in diesem Repository ausgeführt werden soll

• bitbucket-pipelines.yml: Eine Konfigurationsdatei für Bitbucket Pipelines

Bitbucket Pipelines einrichten

Richten wir nun Bitbucket Pipelines so ein, dass Builds für unser Repository ausgeführt werden. Klicken Sie in Ihrem Bitbucket-Repository links auf der Seite auf „Repository-Einstellungen“. Scrollen Sie anschließend im links eingeblendeten Menü nach unten zum Abschnitt „Pipelines“. Klicken Sie auf „Einstellungen“ und dann auf den Schieberegler neben „Pipelines aktivieren“, sodass er grün ist und ein weißes Häkchen anzeigt.

Die Dateien

Sehen wir uns die einzelnen Dateien in unserem Repository an. Wir beginnen mit ec2/instance.tf.

Das anfällige Terraform-Setup

Die Terraform-Datei ec2/instance.tf in der HashiCorp Configuration Language (HCL) deklariert die folgenden AWS-Ressourcen:

• Eine Elastic-Compute-Cloud-Instanz (EC2)

• Eine Identity-and-Access-Management-Rolle (IAM) für den Zugriff auf die oben genannte EC2-Instanz

Um die einfache Funktionsweise von Regula zu demonstrieren, habe ich absichtlich Sicherheitslücken in die EC2-Instanz eingebaut (und Kommentare mit Hinweisen zur Behebung hinzugefügt). Hinweis: Stellen Sie dieses Terraform-Setup nicht in AWS bereit, bevor Sie die Sicherheitsverstöße behoben haben. Sehen wir uns die Sicherheitslücken genauer an:

resource "aws_instance" "app_server18391111" {
    ami           = "ami-074cce78125f09d61"
    instance_type = "t2.micro"

    # Un-comment below to satisfy FG_R00253
    #iam_instance_profile = aws_iam_instance_profile.test_profile.name

    # Make the below declaration = false to satisfy FG_R00271
    associate_public_ip_address = true

    tags = {
        Name = "ExampleAppServerInstance18391111"
        Team = "dev"
    }
}

• Zeile 9 (derzeit auskommentiert) verknüpft unsere EC2-Instanz mit der IAM-Rolle und dem Instance-Profil, die für den Zugriff verwendet werden sollten – statt IAM-Zugriffsschlüsseln. Wenn Sie einer EC2-Instanz beim Start Rolleninformationen übergeben, verringern Sie das Risiko, dass Zugriffsschlüssel offengelegt werden, und tragen dazu bei, zu verhindern, dass böswillige Personen die Instanz kompromittieren.

• In Zeile 12 wird deklariert, dass der EC2-Instanz eine öffentliche IP-Adresse zugewiesen werden soll. Dadurch könnten unbefugte Personen auf Ihre EC2-Instanz zugreifen – selbst wenn Netzwerkzugriffssteuerungslisten oder Sicherheitsgruppen eingerichtet sind.

Wenn wir diese EC2-Instanz unverändert in der Produktionsumgebung bereitstellen, setzen wir uns böswilligen Akteuren aus, die diese Sicherheitslücke mit automatisierten Tools erkennen und ausnutzen könnten, lange bevor wir überhaupt davon erfahren! Zum Glück enthält Regula Hunderte von Regeln, mit denen sich unsere IaC auf Verstöße gegen die CIS-Benchmarks (Center for Internet Security) prüfen lässt.

Bitbucket-Pipelines-Konfiguration

Sehen wir uns genauer an, wie die Datei bitbucket-pipelines.yml Bitbucket Pipelines vorgibt, was bei einem Build zu tun ist. Zunächst teilen wir Bitbucket mit, dass es sich um eine Pipeline handelt – und zwar um die Standard-Pipeline. (Sie können separate Pipelines für Pull Requests, verschiedene Branches des Repositorys oder andere Zwecke erstellen.)

pipelines:
 default:

Ich habe mich dafür entschieden, die folgenden Schritte nacheinander auszuführen. Mit dem Befehl „parallel“ links neben den Schritten könnten sie aber auch parallel ausgeführt werden.

Als Nächstes definiere ich den ersten Schritt. Dabei kommt das HashiCorp-Terraform-Image zum Einsatz, um Terraform zu initialisieren, die Formatierung gemäß den kanonischen HCL-Standards anzupassen und die Gültigkeit des Terraform-Codes zu prüfen (zum Beispiel, ob alle Variablen und Module deklariert sind):

- step:
    name: 1 - Initialize, Format, and Validate Terraform
    image: hashicorp/terraform
    script:
        - terraform init && terraform fmt
        - terraform validate

Der zweite Schritt nutzt Regula, um automatisch alle IaC-Dateien (Terraform, CloudFormation, Azure Resource Manager und Kubernetes-Manifeste) im Stammverzeichnis und in allen Unterverzeichnissen zu erkennen und jede gefundene IaC-Datei anhand der CIS-Benchmark-Standards zu prüfen. (Fugue unterstützt standardmäßig auch weitere Compliance-Frameworks wie SOC 2, HIPAA und NIST 800-53.)

- step:
    name: 2 - Scan Terraform Locally for Security and Compliance with CIS Benchmarks
    image: fugue/regula
    script:
        # Run in root directory first
        - regula run ./
        # Run in child directories next
        - regula run ./*/

Im letzten Schritt wird Terraform erneut initialisiert und noch einmal das HashiCorp-Terraform-Image verwendet, da jeder Schritt in der Bitbucket-Pipeline in einem separaten Docker-Container ausgeführt wird und deklarierte Abhängigkeiten somit nicht zwischen den Schritten übernommen werden. Anschließend erstellt und wendet der letzte Schritt einen Terraform-Plan an:

- step:
    name: 3 - Plan and Apply Secure, Valid Terraform
    image: hashicorp/terraform
    deployment: Production
    trigger: manual
    script:
        - terraform init
        - terraform plan
        - terraform apply -auto-approve

Einen Build starten

Einen Build testen (und scheitern lassen): Nachdem ich die Änderungen an meinem Repository mit IaC-Dateien vorgenommen habe, gebe ich zunächst die folgenden Befehle im Terminal ein:

git add 
git commit -m "initiating the bitbucket pipeline"
git push

Sobald Bitbucket Pipelines den neuen Commit in meinem Repository erkennt (oder manuell dazu aufgefordert wird), startet es die in der obigen .yml-Datei beschriebene Pipeline. Hier sehen Sie, was passiert, wenn ich einen Commit mit Terraform, das gegen die CIS-Benchmarks verstößt, in den Main-Branch des Repositorys pushe:

Konfigurationsprobleme mit Regula beheben

Jetzt weiß ich, dass meine Terraform-Dateien Fehlkonfigurationen enthalten. Deshalb kann ich zu meinem Repository zurückkehren und Regula lokal ausführen, um die Probleme zu beheben. Ich habe das Repository so eingerichtet, dass ich die Korrekturen im Terraform-Code einfach einkommentieren kann. Eine korrekte Konfiguration Ihrer Infrastruktur ist aber auch ganz einfach: Klicken Sie auf den Link zur Dokumentation zur Behebung der jeweiligen Fugue-Regel, der nach jedem Regula-Lauf für jeden Regelverstoß angezeigt wird. Unten sehen Sie, wie ich die Fugue-Regeln FG_R00253 und FG_R00271 behoben und die Infrastruktur anschließend mit einem letzten Regula-Lauf erneut geprüft habe.

Einen Build erfolgreich testen

Nachdem ich meine Infrastruktur korrekt konfiguriert habe, committe ich erneut in mein Bitbucket-Repository, um die Automatisierung meiner eingerichteten Bitbucket-Pipeline bestmöglich zu nutzen.

Ich führe die Befehle vom Anfang erneut aus …

git add 
git commit -m "initiating the bitbucket pipeline"
git push

… und der Build ist erfolgreich:

Das war’s! Jetzt haben wir eine Regula-/Bitbucket-Pipeline, die die Bereitstellung von Cloud-Infrastruktur mit Terraform sicher automatisiert.

Regula lokal ausführen

Zum Glück müssen Sie nicht erst warten, bis Bitbucket Pipelines (oder ein anderes CI/CD-Tool) die Fehler für Sie findet. Sie können Regula lokal ausführen, bevor Sie Ihre Änderungen committen und pushen – und wir empfehlen Ihnen ausdrücklich, das zu tun. Mein persönlicher Favorit ist der Regula-Pre-Commit-Hook. Er sorgt für mehrschichtige Abwehr, indem er Entwicklerinnen und Entwickler dazu zwingt, Sicherheits- und Compliance-Verstöße zu beheben, bevor sie ihren Code committen. Wenn Probleme früher im Entwicklungszyklus erkannt werden, wird Sicherheit weiter nach links verlagert – die Entwicklung wird beschleunigt und Sie sparen später Zeit, Geld und Ärger.

Installieren Sie zunächst Regula lokal. Das Tool ist eine eigenständige Binärdatei, für die keine Voraussetzungen installiert werden müssen. Folgen Sie einfach der Dokumentation für Ihr Betriebssystem.

Führen Sie anschließend im Stammverzeichnis Ihres Repositorys denselben Befehl aus wie Bitbucket Pipelines:

regula run

Sie sehen dieselbe Ausgabe wie in den Bitbucket-Pipelines-Logs. Wenn Sie Regula jedoch lokal ausführen, verbrauchen Sie keine Build-Minuten und übertragen die Verantwortung für Sicherheit auf Entwicklerebene. So lassen sich sicherheitsbedingte Engpässe vor der Bereitstellung verringern oder ganz vermeiden.

Nächste Schritte

Möchten Sie mehr über Regula erfahren? Besuchen Sie unser GitHub-Repository und lesen Sie die Dokumentation. Regula prüft Terraform-HCL, Terraform-Plan-JSON, CloudFormation-YAML/JSON, Kubernetes-YAML-Manifeste und Azure-Resource-Manager-Vorlagen auf Sicherheits- und Compliance-Verstöße. Außerdem unterstützt Regula Ausnahmen, benutzerdefinierte Regeln sowie das Aktivieren und Deaktivieren von Regeln und vieles mehr.

Möchten Sie die sichere Bereitstellung von Cloud-Infrastruktur auf andere Weise automatisieren? Lesen Sie unseren Blogbeitrag zur Integration von Regula und Travis CI.