SonarQube 9.3 – Jetzt mit Terraform Codeanalyse

Mit der neuen SonarQube Version 9.3 soll es nun endlich möglich sein, Terraform Dateien zu scannen und zu analysieren.

Codeanalyse Tools gehören in der modernen agilen Anwendungsentwicklung zum guten Ton, um qualitativ besseren Code bereitzustellen oder bekannte OWASP Sicherheitsrisiken zu erkennen. Diese Tools untersuchen den Quellcode auch nach Programmierfehler wie Null-Pointer-Zuweisungen oder ungeprüften Benutzereingaben.

SonarQube bietet von Haus aus bestimmte Regeln und Qualitätsprofile für die gängigsten Programmiersprachen wie JAVA, C#, Python oder Ruby.
Eine Analyse von Infrastruktur-Codes, welche z.b. mittels Terraform erstellt wurden, war bisher aber nicht möglich. Diese Funktion soll nun in der neuen SonarQube Version endlich verfügbar sein.

Ob das wirklich funktioniert, habe ich mal in einem kleinen Versuchsaufbau getestet. Wie ich das ganze gemacht habe, zeige ich in diesem Artikel. Ich selbst setze für meine Testaufbauten auf Docker Images, da diese schnell und einfach lauffähig sind.

Was ist SonarQube?

Wie eingehend erwähnt, handelt es sich bei SonarQube um ein Codeanalyse Tool zum Optimieren von Quellcode Dateien. Es trägt auch zu einem sichereren Quellcode bei, denn SonarQube erkennt die Sicherheitslücken aus OWASP Top 10 und CWE / SANS Top 25.

Die Code-Inspektion lässt sich über die gängigen CI/CD Tools wie Jenkins oder Github Actions implementieren. Aber auch ein einfacher lokaler Agent steht bei SonarQube bereit, um direkt vom Client die Quellcode-Dateien zu überprüfen. Über die Entwicklungs-IDE lässt sich der Scanner auch recht simple in Maven oder Gradle Projekte implementieren.

SonarQube arbeitet mit Regeln, nach welchen der Quellcode analysiert und ausgewertet wird.

Über die Quality Gates lassen sich Konditionen hinterlegen, die beim Unterschreiten zu einem Abbruch der Pipeline führen können. Somit ist sichergestellt, dass der Quellcode erst eine gewisse Mindestqualität haben muss, bevor die Pipeline die Anwendung komplett baut und bereitstellt.

SonarQube gibt es in unterschiedlichen Editionen. Die kostenfreie Community Edition ist in ihrem Umfang beschränkt. Neben dieser gibt es noch die kostenpflichtigen Developer, Enterprise und Data Center Editionen.

Achtung. Lediglich bei der Data-Center Edition und bei der Enterprise Edition (ab 30 Mio. Codezeilen bei Enterprise) ist auch ein kommerzieller Supportvertrag enthalten.
Für die Enterprise Edition unterhalb 30 Mio. Codezeilen und der Developer Edition kann dieser optional erworben werden.
Alternativ bietet sich noch die SonarSource Community an.

Was ist Terraform?

Gerade im Cloud Umfeld hört man immer wieder etwas von Infrastructure as Code, kurz IaC. Hierbei ist gemeint, eine komplette IT Umgebung mittels Codes zu erstellen. Der Vorteil ist hier, die Wiederverwertbarkeit und Konsistenz einer solchen Infrastruktur. Ebenso ist ein komplettes Rollout einer IT-Infrastruktur, die mittels Code definiert wurde, schneller verfügbar, da weniger manuelle Steps notwendig sind wie bei einem klassischen Aufbau.

Terraform von HashiCorp ist eines dieser IaC Tools, mit denen man für unterschiedliche Cloudanbieter und On-Prem-Systeme Infrastruktur coden kann.

Durch die unterschiedlichen Provider welche Terraform anbietet, lassen sich vom Netzwerk, über VMs bis zum Kubernetes Cluster sämtliche Ressourcen per Code definieren und ausrollen. Selbst lokale VMware ESX oder vCenter Systeme lassen sich hiermit automatisieren.

Die Terraform Konfigurationssprache basiert auf der internen HashiCorp Language, welche auch in anderen Produkten von HashiCorp angewendet werden.

Terraform speichert alle erstellten Ressourcen in einer sogenannten State Datei. Eine Datei mit einer JSON Struktur, welche alle Informationen zu den jeweiligen Ressourcen enthält, die erfolgreich erstellt wurden. Sollten also im Nachgang manuelle Änderungen an den Ressourcen durchgeführt werden, ist der State inkonsistent, da Terraform über diese Änderungen keine Informationen hat.

Der Bitcoin-Standard: Die dezentrale Alternative zum Zentralbankensystem

(1429)

24,00 € (von 23. November 2024 02:20 GMT +01:00 - Mehr InformationenProduct prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on [relevant Amazon Site(s), as applicable] at the time of purchase will apply to the purchase of this product.)

Terraform wird also beim nächsten Deployment die manuellen Änderungen wieder mit den Codebasierten Status überschreiben, im schlimmsten fall muss Terraform die bestehende Ressource abreißen und neu erstellen.

Es empfiehlt sich also bei einem automatisierten Infrastruktur-Deployment die Ressourcen nur noch über den Code zu aktualisieren. Im besten Fall entzieht man den Usern sämtliche Änderungsrechte in den jeweiligen Umgebungen.

Die Terraform State Dateien (tfstate) sollten übrigens zentral abgelegt werden (Remote State). Unterstütze werden hier im übrigen Azure Storage Accounts, Amazon S3 Buckets und GCP Storage Systeme.

Windows10, Linux Subsystem und Docker

Für meinen kleinen Testaufbau habe ich mein Windows 10 Betriebssystem etwas vorbereitet. Da ich SonarQube als Docker Image starten möchte, benötigte ich erst einmal Docker auf meinem PC.

Als Privatanwender ist dies auch recht einfach möglich. Docker bietet mit der Docker-Desktop Variante ein fertiges Paket für Privatanwender, um schnell und einfach Container auszuführen oder sogar einen Minikube Kubernetes Cluster zu betreiben. Docker Desktop lässt sich in 2 Versionen ausführen. Entweder als Hyper-V VM oder mittels des Windows Subsystem for Linux 2 (WSL2).

Kommerzielle Anwender (über 250 Mitarbeiter oder über $10 Millionen USD Jahresumsatz) müssen für Docker Desktop eine kostenpflichtige Subscription abschließen.

Ich habe mich entschlossen auf Docker Desktop zu verzichten und habe mir die Docker Engine direkt auf einem Ubuntu Subsystem eingerichtet.

Im ersten Schritt muss man unter Windows 10 in den Features das Subsystem für Linux aktivieren.

Alternativ kann man in der PowerShell (als Admin ausführen!) auch das folgende Kommando ausführen:

wsl --install

Nach der Installation ist ein Neustart notwendig.

Nun erfolgt die Wahl der Linux Distribution. Ich habe mich hier für Ubuntu entschieden. Es kann aber auch jede andere Distribution aus dem Microsoft Store genutzt werden.

Nach dem ersten Start wird man aufgefordert einen Linux User zu erstellen und das root Kennwort zu setzten. Danach empfiehlt es sich erstmal ein Update und Upgrade durchzuführen.

sudo apt-get update
sudo apt-get upgrade

Was nun noch fehlt, ist die Docker Installation.
Hierzu einfach die Informationen auf der Docker Page befolgen oder das Snippet hier kopieren.

 sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

Danach ist Docker zwar installiert, aber noch nicht gestartet. Dieser startet unter Ubuntu auch nicht automatisch, sondern muss immer manuell gestartet werden.

sudo service docker start

Als abschließenden Test kann man nun einfach die Hello World App als Container starten.

Docker läuft nun also in der WSL und somit geht es nun mit SonarQube weiter.

SonarQube Einrichtung

Für den schnellen Test benötigte ich einfach das aktuelle SonarQube Image aus dem DockerHub. Hier konnte ich direkt das latest Image nehmen, welche die SonarQube Version 9.3 beinhaltet.

 docker pull sonarqube

Eine gesonderte Datenbank habe ich mir nicht aufgebaut, sondern nutze die integrierte H2 Datenbank für meinen Testaufbau.

Da SonarQube aber persistente Daten wie Plugins oder Konfigurationsdaten erstellt, benötigt man noch ein paar Docker volumes.

#create volumes
docker volume create sonarqube-conf
docker volume create sonarqube-data
docker volume create sonarqube-logs
docker volume create sonarqube-extensions

#check volumes
docker volume inspect sonarqube-conf 
docker volume inspect sonarqube-data
docker volume inspect sonarqube-logs
docker volume inspect sonarqube-extensions

Abschließend muss nur noch der SonarQube Container gestartet werden und die Ports gemappt werden.

docker run -d --name sonarqube -p 9000:9000 -p 9092:9092 -v sonarqube-conf:/opt/sonarqube/conf -v sonarqube-data:/opt/sonarqube/data -v sonarqube-logs:/opt/sonarqube/logs -v sonarqube-extensions:/opt/sonarqube/extensions sonarqube

Nach erfolgreichem Start des Containers sollte man über den lokalen Browser nun SonarQube über Port 9000 aufrufen können. (http://localhost:9000)

SonarQube fordert einen noch zum Ändern des Administratorkennworts auf und nach diesem Schritt ist die Einrichtung erst einmal abgeschossen.

Terraform Code Inspection

Bevor ich überhaupt ein Testprojekt angelegt habe, gab es einen Blick in das Ruleset der neuen SonarQube Version. Im Bereich Terraform liefert uns das Tool schon einige Default Rules mit. Allerdings ist ein Großteil der Regeln für den AWS Cloud Provider.

Ein Großteil dieser Regeln sind Überprüfungen auf OWASP Sicherheitslücken. Ich gehe stark davon aus, dass dieses Regelwerk mit zukünftigen Versionen noch erweitert wird.

Aber funktioniert die Codeinspektion überhaupt mit Terraform Dateien(*.tf) oder muss der Scanner hierfür noch extra konfiguriert werden?

In großen Umgebungen lässt man die SonarQube Scans mittels CI/CD Tools durchlaufen, für meinen Test habe ich mir aber einfach mal den lokalen SonarQube Scanner in der aktuellen Version für Windows geholt.

Im „bin“ Verzeichnis des Scanners befindet sich die Agent Batch Datei.
In diesen Ordner habe ich auch einfach meine Terraform Testdatei mit folgendem Inhalt abgelegt.

# Configure the Azure provider
terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 1.65"
    }
  }

  required_version = ">= 1.1.0"
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "rg" {
  name     = "myTFResourceGroup"
  location = "westus2"
}

resource "azurerm_key_vault" "example" {
  name                        = "examplekeyvault"
  location                    = azurerm_resource_group.example.location
  resource_group_name         = azurerm_resource_group.example.name
  enabled_for_disk_encryption = true
  tenant_id                   = "123456"
  soft_delete_retention_days  = 7
  purge_protection_enabled    = none

  sku_name = "standard"

  access_policy {
    tenant_id = "123456"
    object_id = "1231321"

    key_permissions = [
      "Get",
    ]

    secret_permissions = [
      "Get",
    ]

    storage_permissions = [
      "Get",
    ]
  }
}

resource "azurerm_key_vault_key" "generated" {
  name         = "generated-certificate"
  key_vault_id = azurerm_key_vault.example.id
  key_type     = "RSA"
  key_size     = 2048

  key_opts = [
    "decrypt",
    "encrypt",
    "sign",
    "unwrapKey",
    "verify",
    "wrapKey",
  ]
}

resource "azurerm_key_vault_secret" "example" {
  name         = "secret-sauce"
  value        = "szechuan"
  key_vault_id = azurerm_key_vault.example.id
}

Im SonarQube Webinterface fehlt nun noch ein Projekt, welches die Ergebnisse des Scans anzeigen sollen. Hier habe ich ein manuelles Projekt erstellt und den locally Analysemodus gewählt.

Nach Erstellung des Projekts kopiert man sich noch das Kommando für den Scanner heraus und führt diesen direkt aus.

Nach erfolgreichem Scan der Daten wechselt das SonarQube Dashboard auch gleich in das Ergebnisfenster. In meinen Fall wurde ein Security-Issue gefunden und bemängelt.

Kurzum, der Scan von Terraform Dateien (*.tf) funktioniert wunderbar. Allerdings sollte man aktuell noch nicht viel Wert alleine auf das Ergebnis mittels SonarQube legen.

SonarQube kann aktuell eine kleine Beihilfe für Terraform Codes sein, aber ich vermisse weitgehende Regeln wie das Erkennen von Klartext Werten im Bereich von sicherheitsrelevanten Ressourcen wie z.b. KeyVault Einträgen. Solche Inhalte sollten nicht direkt in den Terraform-Dateien stehen, sondern an einem sicheren Ort ausgelagert oder noch besser, automatisiert und randomisiert erstellt werden.

Wer solch eine Auswertung für seinen Terraform-Code möchte, sollte sich mal das kostenfreie Tool tfsec anschauen.

Für bestehende SonarQube Anwender, gibt es mit der neuen Version ein kleines neues Feature für seinen Terraform-Code, welches aber noch Luft nach oben hat.