Kubeaudit, kube-bench, kube-hunter en Trivy gebruiken in Kubernetes

Met een securityscan controleer je of de configuratie van je Kubernetes-workloads en cluster aansluit op beveiligingsrichtlijnen. Kubeaudit, kube-bench, kube-hunter en Trivy onderzoeken ieder een ander deel: workloadconfiguratie, nodeconfiguratie, het aanvalsoppervlak van het netwerk of een combinatie van kwetsbaarheden en configuratiefouten.

In deze handleiding lees je wanneer je welk hulpmiddel gebruikt. Je voert een workload-audit uit met kubeaudit, controleert worker nodes tegen de CIS Kubernetes Benchmark met kube-bench, start een passieve kube-hunter-scan vanuit een Pod en scant manifests en een bestaand cluster met Trivy.

Welk hulpmiddel kies je?

kubeaudit

Kubeaudit beoordeelt Kubernetes-manifests of bestaande workloads op veelvoorkomende onveilige instellingen. Voorbeelden zijn containers die als root draaien, ontbrekende resource limits, een beschrijfbaar rootbestandssysteem, ongewenste Linux-capabilities en ontbrekende NetworkPolicies.

Gebruik kubeaudit vroeg in het ontwikkelproces om YAML-bestanden te controleren of om een bestaande namespace te inventariseren. Omdat het project is gearchiveerd, herkent het niet alle nieuwere Kubernetes-functies en beveiligingsrichtlijnen.

kube-bench

Kube-bench vergelijkt de configuratie van Kubernetes-componenten met de CIS Kubernetes Benchmark. Het controleert bijvoorbeeld bestandsrechten en instellingen van de kubelet. Kube-bench scant geen applicatiecode of kwetsbaarheden in een container image.

Gebruik kube-bench periodiek en na wijzigingen aan de cluster- of nodeconfiguratie. In een managed Kubernetes-omgeving heb je geen toegang tot de control plane. De instructies in deze handleiding controleren daarom alleen een worker node.

kube-hunter

Kube-hunter zoekt vanuit het perspectief van een aanvaller naar bereikbare Kubernetes-services en bekende zwakke plekken. Een scan vanuit een Pod laat zien wat een gecompromitteerde workload vanaf het clusternetwerk kan ontdekken.

Gebruik kube-hunter alleen als aanvullende momentopname in een gecontroleerde omgeving. De tool is niet meer actief in ontwikkeling en een oud resultaat is geen betrouwbare beoordeling van een moderne omgeving.

Trivy

Trivy is een actief onderhouden securityscanner voor onder meer kwetsbaarheden in container images, configuratiefouten in Kubernetes-manifests, hardcoded secrets en te ruime RBAC-rechten. De Kubernetes-clusterscan is volgens Aqua Security nog experimenteel en kan veranderen zonder backwards compatibility.

Gebruik Trivy bij voorkeur voor nieuwe workflows, lokale controles en CI/CD-pipelines. Trivy is breder dan kubeaudit, maar vervangt kube-bench niet volledig: kube-bench blijft de gerichte keuze voor een CIS-controle van Kubernetes-componenten en nodes.

Benodigdheden

Voor deze handleiding heb je het volgende nodig:

• Een Kubernetes-cluster dat van jou is of waarvoor je toestemming hebt om securityscans uit te voeren.
• kubectl, geconfigureerd voor het juiste cluster en context.
• Rechten om een namespace en Jobs te maken. Voor kube-bench zijn daarnaast hostPID en alleen-lezen hostPath-volumes nodig.
• Een lokale teksteditor voor de YAML-bestanden.
• Voor Trivy: internettoegang vanaf je client om Trivy, de vulnerabilitydatabase, controles en container images te downloaden. Voor een clusterscan heeft je kubeconfig minimaal leesrechten nodig voor de resources die je scant.

De kubectl-opdrachten werken hetzelfde in Linux, macOS en Windows PowerShell. Alleen de opdrachten voor het openen van bestanden verschillen per besturingssysteem.

Controleer vóór iedere scan welke context actief is:

kubectl config current-context

Ga alleen verder wanneer de getoonde context bij het bedoelde cluster hoort.

kubeaudit gebruiken

De laatste kubeaudit-release is versie 0.22.2. Gebruik deze versie alleen wanneer je bewust een bestaande kubeaudit-workflow wilt uitvoeren of vergelijken.

Stap 1

Download op de officiële releasepagina van kubeaudit het archief voor je besturingssysteem en processorarchitectuur. Gebruik bijvoorbeeld darwin_arm64 voor een Mac met Apple Silicon en windows_amd64 voor een reguliere 64-bits Windows-client.

Download ook kubeaudit_0.22.2_checksums.txt en bereken vóór het uitpakken de SHA-256-checksum van het archief.

Linux:

sha256sum <archiefbestand>

macOS:

shasum -a 256 <archiefbestand>

Windows PowerShell:

Get-FileHash -Algorithm SHA256 <archiefbestand>

Vervang <archiefbestand> door de naam van het gedownloade bestand. Vergelijk de getoonde checksum met de regel voor hetzelfde archief in kubeaudit_0.22.2_checksums.txt. Pak het archief alleen uit wanneer de waarden exact gelijk zijn.

Linux en macOS:

tar -xzf <archiefbestand>
chmod +x kubeaudit
./kubeaudit version

Windows PowerShell:

tar -xzf <archiefbestand>
.\kubeaudit.exe version

Het argument -a 256 van shasum en het argument -Algorithm SHA256 van Get-FileHash selecteren het SHA-256-algoritme.

Stap 2

Controleer eerst een manifest voordat je het op het cluster toepast.

Linux en macOS:

./kubeaudit all --manifest <bestand.yaml> --minseverity error --no-color --exitcode 0

Windows PowerShell:

.\kubeaudit.exe all --manifest <bestand.yaml> --minseverity error --no-color --exitcode 0

Vervang <bestand.yaml> door het pad naar je Kubernetes-manifest. Het argument --manifest activeert de manifestmodus, --minseverity error toont alleen fouten, --no-color maakt de uitvoer geschikt voor een tekstbestand en --exitcode 0 voorkomt dat een interactieve scan stopt met exitcode 2 wanneer fouten zijn gevonden. Laat --exitcode 0 weg in een CI/CD-pipeline als securityfouten de pipeline moeten laten mislukken.

Stap 3

Controleer zo nodig de workloads in een bestaande namespace. Kubeaudit gebruikt hiervoor de standaard kubeconfig van je lokale gebruiker.

Linux en macOS:

./kubeaudit all --namespace <namespace> --minseverity error --no-color --exitcode 0

Windows PowerShell:

.\kubeaudit.exe all --namespace <namespace> --minseverity error --no-color --exitcode 0

Vervang <namespace> door de namespace die je wilt controleren. De account uit je kubeconfig moet de resources in die namespace mogen weergeven. Kubeaudit wijzigt de resources niet met de opdracht all.

Stap 4

Beoordeel iedere fout op het genoemde resource en de container. Controleer vooral de securityContext, het automatisch koppelen van ServiceAccount-tokens, Linux-capabilities, resource limits en NetworkPolicies. Gebruik de autofix-functie niet rechtstreeks op productiemanifests; pas de voorgestelde wijziging handmatig toe en controleer deze in versiebeheer.

kube-bench gebruiken

De onderstaande configuratie gebruikt kube-bench 0.15.6. Controleer de officiële releases voordat je de configuratie later opnieuw gebruikt en beoordeel release notes voordat je het image-tag bijwerkt.

Kube-bench heeft toegang nodig tot processen en configuratiebestanden op de worker node. De Job gebruikt daarom hostPID en koppelt enkele mappen van de node alleen-lezen. Geef deze rechten alleen aan het versiegebonden kube-bench-image uit de officiële repository.

Stap 1

Maak een afzonderlijke namespace en vraag de namen van je worker nodes op:

kubectl create namespace security-audit
kubectl get nodes

Kies de node die je eerst wilt controleren. Voer de scan later voor iedere worker node afzonderlijk uit, omdat een Job op slechts één node draait.

Stap 2

Open op Linux met nano of op macOS met dezelfde opdracht het bestand kube-bench.yaml:

nano kube-bench.yaml

Gebruik in Windows PowerShell Notepad:

notepad.exe kube-bench.yaml

Voeg de volgende configuratie toe en vervang <node-name> door de naam van de gekozen worker node:

apiVersion: batch/v1
kind: Job
metadata:
  name: kube-bench
  namespace: security-audit
spec:
  backoffLimit: 0
  template:
    metadata:
      labels:
        app: kube-bench
    spec:
      automountServiceAccountToken: false
      hostPID: true
      nodeName: <node-name>
      restartPolicy: Never
      containers:
        - name: kube-bench
          image: docker.io/aquasec/kube-bench:v0.15.6
          command: ["kube-bench", "run", "--targets", "node"]
          volumeMounts:
            - name: var-lib-cni
              mountPath: /var/lib/cni
              readOnly: true
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
              readOnly: true
            - name: etc-systemd
              mountPath: /etc/systemd
              readOnly: true
            - name: lib-systemd
              mountPath: /lib/systemd
              readOnly: true
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
              readOnly: true
            - name: usr-bin
              mountPath: /usr/local/mount-from-host/bin
              readOnly: true
            - name: etc-cni-netd
              mountPath: /etc/cni/net.d
              readOnly: true
            - name: opt-cni-bin
              mountPath: /opt/cni/bin
              readOnly: true
      volumes:
        - name: var-lib-cni
          hostPath:
            path: /var/lib/cni
        - name: var-lib-kubelet
          hostPath:
            path: /var/lib/kubelet
        - name: etc-systemd
          hostPath:
            path: /etc/systemd
        - name: lib-systemd
          hostPath:
            path: /lib/systemd
        - name: etc-kubernetes
          hostPath:
            path: /etc/kubernetes
        - name: usr-bin
          hostPath:
            path: /usr/bin
        - name: etc-cni-netd
          hostPath:
            path: /etc/cni/net.d
        - name: opt-cni-bin
          hostPath:
            path: /opt/cni/bin

De optie --targets node beperkt de scan tot controles voor een worker node. Kube-bench kiest standaard een beschikbare CIS-testset op basis van de Kubernetes-versie die het op de node herkent. Er bestaat geen één-op-éénrelatie tussen iedere Kubernetes-versie en een CIS Benchmark-versie; controleer daarom ook de ondersteunde benchmarkversies.

Stap 3

Sla het bestand op, sluit de teksteditor en start de Job:

kubectl apply -f kube-bench.yaml
kubectl wait --for=condition=complete job/kube-bench --namespace security-audit --timeout=180s
kubectl logs job/kube-bench --namespace security-audit

De wait-opdracht wacht totdat de Job gereed is. Het optionele argument --timeout=180s stopt het wachten na 180 seconden. Controleer met kubectl describe job kube-bench --namespace security-audit waarom de Job niet start wanneer de timeout verloopt.

Stap 4

De uitvoer gebruikt PASS voor een geslaagde controle, FAIL voor een gevonden afwijking en WARN voor een controle die je handmatig moet beoordelen. Een FAIL betekent niet automatisch dat het cluster kwetsbaar is. Bestandspaden en implementatiedetails kunnen afwijken van de aannames in de CIS-test.

In een managed Kubernetes-cluster vallen de control plane en hostconfiguratie onder het beheer van de provider. Pas de getoonde node-remediations niet zelf toe op provider-managed nodes. Gebruik de bevindingen die binnen jouw beheer vallen om workloads te verbeteren en neem contact op met TransIP wanneer een bevinding betrekking heeft op de managed laag.

Wil je een volgende worker node scannen? Verwijder eerst de Job, vervang nodeName in kube-bench.yaml en pas het bestand opnieuw toe:

kubectl delete job kube-bench --namespace security-audit
kubectl apply -f kube-bench.yaml

kube-hunter gebruiken

De volgende Job gebruikt kube-hunter 0.6.8 in passieve Pod-modus. De Job krijgt geen ServiceAccount-token en laat Linux-capabilities vallen. Hierdoor onderzoekt kube-hunter welke services vanaf het Pod-netwerk bereikbaar zijn, zonder de rechten van een gekoppeld ServiceAccount-token te testen.

Stap 1

Open op Linux of macOS het bestand kube-hunter.yaml:

nano kube-hunter.yaml

Gebruik in Windows PowerShell Notepad:

notepad.exe kube-hunter.yaml

Voeg de volgende configuratie toe:

apiVersion: batch/v1
kind: Job
metadata:
  name: kube-hunter
  namespace: security-audit
spec:
  backoffLimit: 0
  activeDeadlineSeconds: 180
  template:
    metadata:
      labels:
        app: kube-hunter
    spec:
      automountServiceAccountToken: false
      restartPolicy: Never
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: kube-hunter
          image: docker.io/aquasec/kube-hunter:0.6.8
          command: ["kube-hunter"]
          args: ["--pod"]
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]

De optie --pod start de ontdekking vanuit het clusternetwerk. activeDeadlineSeconds beëindigt de Job wanneer deze na 180 seconden nog actief is. De container gebruikt het vaste image-tag 0.6.8 in plaats van latest, zodat een volgende uitvoering niet onverwacht andere code gebruikt.

Stap 2

Sla het bestand op, sluit de teksteditor en start de passieve scan:

kubectl apply -f kube-hunter.yaml
kubectl wait --for=condition=complete job/kube-hunter --namespace security-audit --timeout=180s
kubectl logs job/kube-hunter --namespace security-audit

De uitvoer bevat gevonden nodes, bereikbare services en mogelijke kwetsbaarheden. De IDs verwijzen naar beschrijvingen in de Aqua Vulnerability Database. Deel de volledige uitvoer niet openbaar: evidence kan interne adressen en configuratiegegevens bevatten.

Stap 3

Controleer eerst of een bevinding nog van toepassing is op je Kubernetes-versie. Bevestig daarna met kubectl en de actuele Kubernetes-documentatie of de gevonden service of instelling daadwerkelijk ongewenst bereikbaar is. Behandel een kube-hunter-resultaat nooit als enige bewijs voor een kwetsbaarheid.

Trivy gebruiken

Met Trivy controleer je eerst lokale manifests en daarna de resources in het actieve cluster. De voorbeelden gebruiken Trivy 0.72 of nieuwer. Controleer bij een nieuwere versie altijd de actuele Trivy-documentatie, omdat de Kubernetes-clusterscan nog experimenteel is.

Stap 1

Installeer Trivy op de client waarmee je het cluster beheert.

sudo apt-get install wget gnupg
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | gpg --dearmor | sudo tee /usr/share/keyrings/trivy.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/trivy.gpg] https://aquasecurity.github.io/trivy-repo/deb generic main" | sudo tee /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy

brew install trivy

Expand-Archive -Path .	rivy_0.72.0_windows-64bit.zip -DestinationPath .	rivy

Controleer de installatie:

trivy --version

Gebruik je Windows en staat Trivy niet in PATH? Voer de volgende opdrachten dan vanuit de uitgepakte map uit en gebruik trivy.exe in plaats van trivy.

Stap 2

Open een terminal in de map met je Kubernetes-manifests en scan alle ondersteunde configuratiebestanden in de huidige map:

trivy config --severity HIGH,CRITICAL .

Trivy herkent onder meer Kubernetes YAML, Helm Charts en Dockerfiles. De optie --severity beperkt de uitvoer tot bevindingen met de ernst HIGH en CRITICAL. De punt aan het einde verwijst naar de huidige map. Geef in plaats daarvan een bestandsnaam of ander pad op als je een afzonderlijk manifest of een andere map wilt scannen.

Bij de eerste scan downloadt Trivy controles en databases. Daardoor kan de eerste uitvoering langer duren en is internettoegang nodig.

Stap 3

Controleer opnieuw de actieve kubectl-context en start daarna een samenvattende clusterscan:

kubectl config current-context
trivy k8s --report=summary --disable-node-collector

Trivy gebruikt standaard de actieve context uit je kubeconfig. De optie --report=summary toont een compact overzicht. Met --disable-node-collector maakt Trivy geen node-collector-Jobs in het cluster. Bevindingen over de configuratie van nodes ontbreken dan; gebruik daarvoor de kube-bench-scan uit deze handleiding.

Beperk een gedetailleerde scan bij voorkeur tot één namespace:

trivy k8s --include-namespaces <namespace> --severity=HIGH,CRITICAL --report=all --disable-node-collector

Vervang <namespace> door de namespace die je wilt scannen. De optie --include-namespaces beperkt de scan tot die namespace, --severity toont alleen bevindingen met de ernst HIGH en CRITICAL en --report=all toont de details per resource.

Stap 4

Sla een volledig rapport op in JSON-formaat als je de resultaten geautomatiseerd wilt verwerken:

trivy k8s --report=all --format=json --output=trivy-kubernetes-report.json --disable-node-collector

De optie --format=json maakt de uitvoer machineleesbaar en --output schrijft die naar trivy-kubernetes-report.json. Het rapport kan namen van resources, kwetsbaarheden en andere interne informatie bevatten. Bewaar het daarom op een locatie met passende toegangsrechten.

Wil je een CI/CD-pipeline laten stoppen bij een lokale HIGH- of CRITICAL-bevinding? Gebruik dan:

trivy config --severity=HIGH,CRITICAL --exit-code=1 .

De optie --exit-code=1 laat Trivy afsluiten met statuscode 1 wanneer een passende bevinding wordt gevonden. Controleer de resultaten handmatig voordat je een uitzondering toevoegt of een deployment blokkeert.

De scanresources verwijderen

Verwijder de namespace nadat je de rapporten veilig hebt opgeslagen en beoordeeld. Hiermee verwijder je de kube-bench- en kube-hunter-Jobs en de bijbehorende Pods:

kubectl delete namespace security-audit

Bewaar rapporten alleen op een locatie met passende toegangsrechten en verwijder interne IP-adressen, tokens en andere gevoelige evidence voordat je een rapport deelt.

Je weet nu welk deel van Kubernetes kubeaudit, kube-bench, kube-hunter en Trivy controleren en hoe je iedere tool binnen zijn beperkingen gebruikt. Combineer periodieke CIS-controles met Trivy-scans van manifests en clusters, gecontroleerde netwerkscans en handmatige beoordeling om het beveiligingsniveau van je cluster gericht te verbeteren.