Kubernetes Audit

A read-only kubeconfig or a ServiceAccount with cluster-wide get / list / watch verbs only, scoped to the audit window. We never apply, exec, port-forward, or modify anything. We do not read Secret data, the contents of ConfigMaps used as secrets, or PersistentVolume contents - only cluster, workload, and policy specs plus aggregated utilisation metrics. Step-by-step setup guides are included for EKS, GKE, AKS, OpenShift, Rancher, and self-managed clusters.

All major distributions: Amazon EKS, Google GKE (including Autopilot), Azure AKS, Red Hat OpenShift / OKD, Rancher / RKE / RKE2 / K3s, and self-managed Kubernetes (kubeadm, kops). The audit also covers common platform add-ons - Istio and Linkerd (service mesh), Cilium and Calico (CNI / network policy), ArgoCD and Flux (GitOps), Karpenter and Cluster Autoscaler (scaling), Kyverno and OPA/Gatekeeper (admission), Falco (runtime), and Kubecost / OpenCost (cost).

Yes. Findings are mapped to specific controls in the CIS Kubernetes Benchmark, the NSA/CISA Kubernetes Hardening Guide, and the Pod Security Admission restricted profile, plus the relevant SDLC controls in SOC 2 CC8.1, ISO 27001, PCI-DSS 6, and HIPAA technical safeguards. The output is designed to drop directly into auditor evidence packs.

Those tools produce raw findings; this audit interprets them. A senior Kubernetes engineer triages every finding for actual blast radius and exploitability against your context, removes false positives (e.g. permissive workloads with compensating controls), and combines results across kube-bench, kube-hunter, Trivy, Polaris, Pluto, KubeLinter, and Goldilocks with a manual review of admission control, networking, GitOps, and cost posture - into a prioritised, ticket-ready remediation plan rather than a 4,000-line report.

Yes - most teams see 20-40% over-provisioned compute on first audit. We use Kubecost / OpenCost data where you have it, profile request-vs-usage with Goldilocks / VPA, and recommend Karpenter, Cluster Autoscaler, Spot / Preemptible, and KEDA changes with quantified $/month savings. You can also choose a cost-first focus during scoping if cost is the primary driver.

No. The audit is fully read-only and works against the API server's get / list / watch verbs at a controlled rate. Nothing we do can drain a node, evict a pod, modify RBAC, or trigger autoscaling. You can run the audit during normal business hours with zero risk to delivery.

We can audit a single cluster, a representative sample, or a full fleet. For fleet-wide audits we deduplicate findings (e.g. a misconfiguration shared across 30 clusters becomes one finding with affected-cluster list), surface drift between clusters that should be identical (production / staging parity), and prioritise based on environment criticality and exposure.

Typical turnaround is 1-2 business days from the moment read-only access is granted, plus a 45-minute live findings walkthrough at a time that suits your team. Larger fleets with dozens of clusters can take a little longer; we confirm the timeline as soon as we see the scope.