Cloud, Container & IaC Security

Episode 02/5 — Dive + kube-bench

Tool versions: Dive 0.13.1 + kube-bench 0.16.0

Pendahuluan

Vulnerability scanning menjawab apa yang rentan, tetapi security assessment juga perlu mengetahui apa yang benar-benar berada di dalam artifact dan apakah Kubernetes memiliki baseline konfigurasi yang baik.

Dive digunakan untuk melihat layer dan isi container image. kube-bench digunakan untuk memeriksa kontrol Kubernetes terhadap CIS Kubernetes Benchmark.

1. Dive

Verifikasi:

dive --version

Analisis image:

dive nginx:alpine

Periksa setiap layer dan file changes.

2. Mengapa layer penting?

Contoh Dockerfile yang buruk:

COPY .env /app/.env
RUN rm /app/.env

Menghapus file pada layer berikutnya tidak sama dengan tidak pernah memasukkan secret ke image.

Periksa image dengan Dive dan pastikan secret, credential, SSH key, build artifact dan cache tidak masuk ke production image.

3. Multi-stage build

Gunakan build stage terpisah:

FROM node:22 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html

Kemudian:

docker build -t myapp:secure .
dive myapp:secure

Tujuannya bukan hanya image kecil. Runtime image juga memiliki lebih sedikit komponen yang harus dipelihara dan di-scan.

4. Dive bukan vulnerability scanner

Dive memberikan visibility terhadap struktur image. Gunakan bersama Trivy atau Grype untuk vulnerability matching.

Dive → layer and file visibility
Trivy/Grype → vulnerability

5. kube-bench

kube-bench memeriksa konfigurasi Kubernetes berdasarkan CIS Kubernetes Benchmark.

Verifikasi:

kube-bench version
kube-bench run
kube-bench run --help

Target dan command dapat berbeda berdasarkan environment dan release.

6. Memahami hasil

PASS berarti kontrol yang diperiksa terpenuhi.

FAIL berarti kontrol tidak memenuhi benchmark.

FAIL bukan bukti bahwa cluster sudah compromised.

PASS juga bukan bukti bahwa cluster aman secara keseluruhan.

Gunakan:

FAIL → Understand → Validate → Remediate → Re-test

7. Area assessment

Review API server, authentication, authorization, etcd, scheduler, controller manager, kubelet, file permissions, audit logging dan workload security sesuai benchmark.

Jangan mengubah production configuration hanya berdasarkan satu output. Beberapa perubahan dapat memengaruhi availability atau compatibility.

8. Permission

Deployment kube-bench tertentu membutuhkan akses host filesystem atau process namespace.

Pahami permission tersebut sebelum menjalankannya pada production.

9. Container dan cluster adalah dua layer

Image yang aman tidak membuat cluster otomatis aman.

Cluster yang hardened juga tidak membuat image otomatis bebas vulnerability.

Workflow:

Container image
 ↓
Dive
 ↓
Trivy/Grype
 ↓
Kubernetes deployment
 ↓
kube-bench
 ↓
Configuration remediation

10. Hardening checklist

Container:

• tidak ada secret;
• runtime image minimal;
• build dependency dipisahkan;
• image dipin atau menggunakan digest;
• vulnerability scan tersedia;
• SBOM tersedia.

Kubernetes:

• RBAC;
• API server;
• kubelet;
• etcd;
• audit;
• network policy;
• pod security;
• privileged workloads;
• host namespace exposure.

11. Kesalahan umum

Jangan menganggap image kecil otomatis aman.

Jangan menghapus secret setelah secret masuk image layer.

Jangan menganggap kube-bench PASS sebagai security score.

Jangan melakukan remediation langsung pada production tanpa memahami impact.

Kesimpulan

Dive mengajarkan visibility terhadap artifact. kube-bench mengajarkan baseline terhadap platform. Keduanya membantu membangun hardening process yang lebih disiplin karena remediation dilakukan setelah kondisi aktual diketahui.

Referensi resmi

• https://github.com/wagoodman/dive
• https://github.com/aquasecurity/kube-bench
• https://www.cisecurity.org/benchmark/kubernetes

Seri: Cloud, Container & IaC Security
Episode: 02/5
Tools: Dive + kube-bench