Einen Kubernetes-Pod mit Regula und Open Policy Agent absichern

Fugue hat kürzlich Kubernetes-Unterstützung für Regula veröffentlicht, unsere Open-Source-Policy-Engine zur Prüfung von Infrastructure as Code. Regula kann nicht nur Ihre Terraform- und CloudFormation-Dateien auf Sicherheits- und Compliance-Verstöße prüfen, sondern jetzt auch Kubernetes-YAML-Manifeste!

In diesem Blogbeitrag zeigen wir Ihnen, wie Sie Regula auf ein Kubernetes-Manifest anwenden, um einen unsicheren Pod zu erkennen und anschließend abzusichern. Als Bonus entspricht die finale Version des Manifests dem CIS Kubernetes Benchmark v1.6.1, einer Reihe von Empfehlungen zur Absicherung von Kubernetes-Umgebungen.

Bereit? Los geht’s!

Erste Schritte

Installieren Sie zunächst Regula. Homebrew-Nutzer können die folgenden Befehle ausführen:

brew tap fugue/regula
brew install regula

Alternativ können Sie eine vorkompilierte Binärdatei für Ihre Plattform installieren oder, wenn Sie möchten, Regula mit Docker ausführen.

Beim Verfassen dieses Beitrags haben wir Regula v1.5.0 verwendet.

Rufen Sie anschließend unser GitHub-Gist auf, wählen Sie die Schaltfläche „Download ZIP“ und entpacken Sie die Dateien. Es sind zwei:

• pod.yaml: Ein nicht konformes, unsicheres Kubernetes-Manifest

• pod-compliant.yaml: Eine konforme, abgesicherte Version desselben Manifests

Während wir erklären, wie Sie die einzelnen Verstöße beheben, können Sie zu Hause mitmachen, indem Sie pod.yaml manuell bearbeiten. Oder Sie beziehen sich einfach auf die abgesicherte Version pod-compliant.yaml.

Das Manifest prüfen

Unser Manifest deklariert einen einfachen Pod namens hello mit einem einzelnen BusyBox-Container, der ebenfalls hello heißt:

apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
    - name: hello
      image: busybox
      command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']

Er sieht nicht unsicher aus, oder? Aber führen wir Regula aus, um sicherzugehen.

Regula ausführen

Wechseln Sie in Ihrem Terminal in das Verzeichnis mit den heruntergeladenen Dateien. Wir führen Regula mit dem Flag --format compact auf pod.yaml aus, um Platz zu sparen:

regula run pod.yaml --format compact

Die Ausgabe lautet:

Oje! Unser Pod ist definitiv nicht so sicher, wie er sein könnte. Regula hat 6 Probleme gefunden.

Keine Sorge – wir können sie alle beheben! Sehen wir uns die einzelnen Verstöße an, damit wir sie korrigieren können.

Verstöße beheben

Service-Account-Tokens

Der Verstoß: „Service account ‘automountServiceAccountToken’ should be set to ‘false’ [Medium]“

Die CIS-Kubernetes-v1.6.1-Kontrolle: 5.1.6, „Ensure that Service Account Tokens are only mounted where necessary“

Warum das wichtig ist: Service-Account-Tokens dienen dazu, Anfragen von Prozessen innerhalb des Clusters an den Kubernetes-API-Server zu authentifizieren. Standardmäßig werden Service-Account-Tokens automatisch in alle Pods eingebunden. Kann ein Angreifer jedoch einen einzelnen Pod kompromittieren, könnte er dessen Service-Account-Token nutzen, um einen Angriff zur Rechteausweitung zu starten und die Kontrolle über den gesamten Cluster zu erlangen.

Wenn eine Workload also nicht mit dem API-Server kommunizieren muss, sollten Sie ein Service-Account-Token nicht automatisch einbinden lassen. Das entspricht dem Sicherheitsprinzip der geringsten Berechtigung.

So beheben Sie das Problem: Setzen Sie automountServiceAccountToken in der Pod-Spezifikation auf false:

spec:
  automountServiceAccountToken: false

Siehe Zeile 10 in pod-compliant.yaml.

Root-Benutzer

Der Verstoß: „Pods should not run containers as the root user [Medium]“

Die CIS-Kubernetes-v1.6.1-Kontrolle: 5.2.6, „Minimize the admission of root containers“

Warum das wichtig ist: Unnötig als Root zu arbeiten, ist fast immer eine schlechte Idee. Wird ein Container als Root ausgeführt, kann ein Angreifer bei einem Container-Ausbruch Root-Rechte auf dem Hostsystem erlangen.

So beheben Sie das Problem: Legen Sie in der Pod-Spezifikation für runAsUser eine beliebige Benutzer-ID ungleich null fest, denn 0 steht für Root:

spec:
  securityContext:
    runAsUser: 1001

Siehe Zeilen 8–9 in pod-compliant.yaml.

Sie müssen sicherstellen, dass der hier angegebene Benutzer im Docker-Image definiert ist. Häufig wird ein Benutzer ohne Root-Rechte mit dem Linux-Befehl useradd in der Dockerfile angelegt. Anschließend wird die Benutzer-ID über den USER-Befehl angegeben.

Linux-Capabilities

Die nächsten beiden Verstöße hängen eng zusammen und lassen sich in unserem Beispiel auf dieselbe Weise beheben.

Der Verstoß: „Pods should not run containers with the NET_RAW capability [Medium]“

Die CIS-Kubernetes-v1.6.1-Kontrolle: 5.2.7, „Minimize the admission of containers with the NET_RAW capability“

Der Verstoß: „Pods should not run containers with default capabilities assigned [Medium]“

Die CIS-Kubernetes-v1.6.1-Kontrolle: 5.2.9, „Minimize the admission of containers with capabilities assigned“

Warum das wichtig ist: Einem Linux-Container wird bei seiner Ausführung ein Standardsatz an Capabilities zugewiesen, die Prozessen bestimmte Root-Rechte verleihen. Die NET_RAW-Capability ist besonders gefährlich, da Angreifer damit Netzwerkverkehr überwachen oder IP-Datenverkehr mit gefälschten Adressen erzeugen können.

Viele Services benötigen nicht alle Standard-Capabilities. Daher empfiehlt es sich, zunächst alle zu entfernen und anschließend nur die erforderlichen wieder hinzuzufügen. In diesem Beispiel fügen wir keine hinzu; bei Bedarf könnten Sie dies mit add: ["FOO"] tun.

So beheben Sie das Problem: Legen Sie für den Container einen securityContext fest und geben Sie mit drop: ["ALL"] an, dass alle Capabilities entfernt werden sollen. Damit beheben Sie beide Verstöße auf einmal. (Bei Bedarf können Sie auch mit drop: ["NET_RAW"] nur Verstoß 5.2.7 beheben.):

spec:
  containers:
    - name: hello
      securityContext:
        capabilities:
          drop: ["ALL"]  

Siehe Zeilen 15–17 in pod-compliant.yaml.

Seccomp-Profil

Der Verstoß: „Pod seccomp profile should be set to ‘docker/default’ [Medium]“

Die CIS-Kubernetes-v1.6.1-Kontrolle: 5.7.2, „Ensure that the seccomp profile is set to docker/default in your pod definitions“

Warum das wichtig ist: Unter Linux beschränkt der Secure Computing Mode (seccomp), welche Systemaufrufe (Syscalls) zulässig sind. Container-Runtimes wie Docker stellen in der Regel ein Standard-seccomp-Profil bereit, das eine Reihe von Syscalls deaktiviert und so die Sicherheit erhöht.

Beachten Sie, dass das Profil docker/default in Kubernetes 1.11 als veraltet eingestuft wurde. Entgegen der Empfehlung in CIS Kubernetes v1.6.1 sollten Sie daher besser runtime/default verwenden.

So beheben Sie das Problem: Je nach Kubernetes-Version gibt es mehrere Möglichkeiten. In Versionen vor v1.19 können Sie dazu die Annotation seccomp.security.alpha.kubernetes.io/pod in den Pod-Metadaten verwenden:

metadata:
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

Siehe Zeilen 5–6 in pod-compliant.yaml.

Security Context

Der Verstoß: „Pods and containers should apply a security context [Medium]“

Die CIS-Kubernetes-v1.6.1-Kontrolle: 5.7.3, „Apply Security Context to Your Pods and Containers“

Warum das wichtig ist: Ein Security Context für einen Pod oder Container definiert verschiedene Sicherheitseinstellungen für Zugriffskontrolle, Linux-Capabilities und Berechtigungen. Es empfiehlt sich, die für Ihren konkreten Anwendungsfall relevanten Parameter festzulegen.

So beheben Sie das Problem: Sie können einen Security Context auf Pod- oder Containerebene festlegen. Sind Einstellungen auf beiden Ebenen definiert und überschneiden sie sich, haben die Containereinstellungen Vorrang vor den Pod-Einstellungen.

Weiter oben haben wir auf Pod-Ebene einen securityContext festgelegt, um die Ausführung als Root zu verhindern, und auf Containerebene alle Capabilities entfernt. Damit haben wir diesen Verstoß bereits behoben.

Siehe Zeilen 8–9 und 15–17 in pod-compliant.yaml.

Regula erneut ausführen

Nachdem wir alle 6 Verstöße behoben haben, sehen wir uns an, was Regula zu unserem jetzt abgesicherten Pod sagt. Hier ist das aktualisierte Manifest, das wir Ihnen praktischerweise als pod-compliant.yaml bereitgestellt haben:

apiVersion: v1
kind: Pod
metadata:
  name: hello
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: "runtime/default" 
spec:
  securityContext:
    runAsUser: 1001
  automountServiceAccountToken: false
  containers:
    - name: hello
      image: busybox
      command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      securityContext:
        capabilities:
          drop: ["ALL"]

Wenn Sie pod.yaml Schritt für Schritt bearbeitet haben, führen Sie denselben Befehl wie zuvor aus:

regula run pod.yaml --format compact

Wenn Sie pod.yaml nicht bearbeitet haben (kein Urteil!), können Sie Regula einfach auf das Manifest pod-compliant.yaml anwenden:

regula run pod-compliant.yaml --format compact

Die Ausgabe:

No problems found. Nailed it.

Tada! Wir haben alle Probleme, die Regula bei unserem unsicheren Pod gefunden hat, erfolgreich behoben. Gute Arbeit!

Wie geht es weiter?

Nachdem Sie gelernt haben, wie Sie mit Regula ein Kubernetes-Manifest absichern, lesen Sie weitere Best Practices für Kubernetes-Sicherheit.

Mehr über Regula erfahren Sie unter regula.dev. Dort finden Sie eine Liste all unserer Kubernetes-Regeln. Außerdem erfahren Sie, wie Sie ein Regelergebnis ausnehmen oder eine Regel sogar vollständig deaktivieren, wenn sie für Ihr Unternehmen nicht relevant ist.