Sample only
See a Sample Kubernetes Audit Report
This public example shows how findings are organized, evidenced, and prioritized. The sample cluster is a self-managed K3s production environment running Longhorn, CloudNativePG (PostgreSQL), MetalLB, ingress-nginx, cert-manager, and Argo CD, so the report covers the platform layer as well as core Kubernetes configuration. A real assessment is tailored to the agreed environment and scope.
This sample report uses fictional data (cluster: production-demo, documentation-only IP ranges and *.demo.example hosts) and is provided solely to demonstrate the structure and level of detail of a Kubernetes Cluster Audit. It contains no real customer, infrastructure, or credential information.
Download the Sample Audit Report
61 findings across security, RBAC, network exposure, availability, storage, PostgreSQL, backups, capacity, and GitOps. Each has a severity, a confidence level, sanitized configuration evidence, impact, remediation, validation, and rollback steps.
Download Sample PDF Report
Machine-readable versions of the same findings: JSON · CSV
Overall healthPoor
Critical2
High24
Medium17
Low15
Informational3
What the report contains
- Executive health scorecard: a rating per domain (control plane, workload security, identity, network exposure, availability, storage, backup and recovery, capacity, GitOps, observability), separating confirmed risks from findings that need confirmation and from best-practice deviations.
- Scope and coverage: what was assessed, partially assessed, and not assessed (for example control-plane flags, node OS, or RTO), so a clean area is never confused with an unexamined one.
- Root causes: related findings grouped under the underlying cause, such as no enforced workload baseline, backups that have never been proven, or single points of failure.
- Phased remediation roadmap: what to fix within 7, 30, and 90 days, with effort estimates.
- Detailed findings: what was found, the configuration evidence, impact, remediation, how to validate the fix, and how to roll it back.
- Appendices: external exposure inventory, per-node capacity with N-1 headroom, and observed backup recovery points.
K8S-PG-004 High
PostgreSQL backups or WAL archiving are failing
Confidence: Confirmed · Type: Risk · Effort: under a day
What we found
The payments-db CloudNativePG cluster has backups configured, but the evidence shows they are not currently producing usable recovery points.
Evidence
data/payments-db: ContinuousArchiving=False (barman-cloud-wal-archive: AccessDenied)
latest Backup payments-db-daily-20261025030000 failed: AccessDenied writing to s3://demo-pg-backups
last successful base backup 5 days ago (2026-10-21T03:04:12Z)
Impact
The configuration suggests the database is protected, but the achievable recovery point keeps getting older. Point-in-time recovery would lose everything after the last archived WAL segment.
Recommendation and validation
Fix the archive destination (credentials, bucket permissions, network egress), take an on-demand backup, and confirm with kubectl cnpg status that continuous archiving is working and the new backup completed.
K8S-RBAC-003 High
cluster-admin ClusterRole granted within a namespace
Confidence: Confirmed · Type: Risk · Effort: under a day
What we found
A RoleBinding in the payments namespace grants the cluster-admin ClusterRole to the deploy-bot service account. Through a RoleBinding, these permissions apply only inside that namespace, not cluster-wide.
Evidence
RoleBinding payments/deploy-bot-admin -> ClusterRole cluster-admin
subjects: ServiceAccount payments/deploy-bot
namespace has no enforced Pod Security Standard: privileged pods can be created
Impact
Within payments, the service account can read every Secret and create Roles, RoleBindings, and pods. Because the namespace does not enforce a Pod Security Standard, it can also create a privileged pod and escape to the node. That escape path is why this is rated High rather than Medium.
Recommendation and validation
Replace the binding with a Role limited to what the bot uses, enforce at least the baseline Pod Security Standard on the namespace, and confirm with kubectl auth can-i --list -n payments --as=system:serviceaccount:payments:deploy-bot.
These two findings are a quick preview. Download the full PDF report to see all 61 findings, the scorecard, the scope and coverage table, and the phased remediation roadmap.
Want this assessment for your cluster?
The Kubernetes Cluster Audit is a fixed-price $300 engagement with a written report, prioritized remediation recommendations, and a live walkthrough.