Erich Blume d021b3534f

Build Container / detect (push) Successful in 4s

Details

Build Container / build-dockerfile (prowler) (push) Successful in 10s

Details

## Summary
- Deploy Prowler 5 as a weekly CronJob on minikube-indri for CIS Kubernetes Benchmark v1.11 scanning
- Custom slim container build (strips PowerShell, Trivy, and non-K8s providers from upstream)
- Reports (HTML, CSV, JSON-OCSF) written to NFS share on sifaka at `/volume1/reports/prowler/`
- Read-only ClusterRole for pod, RBAC, and control plane inspection
- Host path mounts + hostPID for kubelet file permission checks

## Follow-ups
- Mirror prowler-cloud/prowler on forge for supply chain control
- Build and push container image, update kustomization.yaml newTag
- Consider adding k3s-ringtail scanning (core + RBAC checks only)

## Test plan
- [ ] Build container: `mise run container-release prowler v5.22.0`
- [ ] Update `argocd/manifests/prowler/kustomization.yaml` newTag to built image tag
- [ ] Sync ArgoCD: `argocd app sync apps && argocd app set prowler --revision deploy-prowler && argocd app sync prowler`
- [ ] Trigger manual job: `kubectl create job --from=cronjob/prowler prowler-manual -n prowler --context=minikube-indri`
- [ ] Verify reports appear on sifaka NFS share
- [ ] `mise run services-check`

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Reviewed-on: #310

2026-03-24 16:08:09 -07:00

2.8 KiB

Raw Blame History

title

modified

last-reviewed

Read Compliance Reports

How to access and interpret compliance scan reports from prowler and other security scanners.

Accessing reports

Reports are stored on sifaka at /volume1/reports/. Each scanner writes to its own subdirectory:

Scanner	Path	Schedule
prowler	`sifaka:/volume1/reports/prowler/`	Weekly (Sunday 3am)

Copy reports to your local machine (remember scp -O for sifaka):

scp -O sifaka:/volume1/reports/prowler/prowler-output-In-Cluster-*.html /tmp/
open /tmp/prowler-output-In-Cluster-*.html

Report formats

HTML

Open in a browser. Self-contained, filterable by severity, status, and service. Best for human review — shows pass/fail per check with remediation guidance.

CSV

One row per finding. Columns include check ID, status, severity, resource, namespace, description, and remediation. Good for filtering in a spreadsheet or scripting.

JSON-OCSF

Open Cybersecurity Schema Framework format. Machine-parseable, suitable for SIEM ingestion or programmatic analysis.

Compliance CSV

In the compliance/ subdirectory. Findings mapped to specific framework requirement IDs (e.g., CIS 1.11 section numbers). Shows which controls pass or fail.

Interpreting results

Status values

PASS — the resource is configured securely per the check
FAIL — remediation is recommended
MANUAL — Prowler cannot determine the result automatically (e.g., kubelet file permissions when not running on the node)
MUTED — the finding was explicitly suppressed via a mutelist

Severity

Findings are categorized as critical, high, medium, or low. Focus on critical and high first.

Expected failures

Not all failures require action. Common expected failures in our minikube cluster:

Core/pod security (high): System pods (ArgoCD, external-secrets, tailscale-operator) legitimately need elevated privileges. These can be mutelisted.
Apiserver (medium): Audit logging, profiling, and some admission plugins are not configured in minikube defaults. Low risk for a homelab.
Kubelet (high): Anonymous auth or read-only port settings from minikube defaults.

Acting on findings

Triage — review new failures, distinguish real issues from expected noise
Remediate — fix what you can (pod security contexts, RBAC tightening)
Mutelist — suppress expected/accepted failures via Prowler's --mutelist-file to reduce noise in future scans
Track — compare reports over time to spot regressions

2.8 KiB Raw Blame History