Kubernetes Security Scanning: Complete Guide with Prowler

The Challenge: Kubernetes Is Secure by Default in Almost No Way

Kubernetes gives you a powerful platform with insecure defaults and an enormous configuration surface. A pod can run as root, mount the host filesystem, and talk to every other pod on the network, all without anyone explicitly allowing it. RBAC is permissive when you are not careful, secrets sit base64-encoded rather than encrypted, and the control plane has dozens of flags that change your security posture in ways most teams never review.

The result is a sprawling attack surface that changes every time someone ships a deployment. And the teams running these clusters are already underwater. In Prowler's State of Cloud Security 2026 report, a survey of 633 security professionals, teams reported handling an average of 71 incidents per week, over 3,600 a year, with most of that time going to manual triage rather than fixing root causes. The same report found that 42% name skills shortages as their biggest operational barrier, and Kubernetes expertise is one of the hardest skills to hire for.

Visibility makes it worse. Only 31% of teams rate their cloud visibility as better than "average," and a cluster is one of the hardest places to see clearly. Workloads are ephemeral, RBAC bindings stack on top of each other, and a single misconfigured ServiceAccount can quietly grant cluster-admin. You cannot review that by reading YAML by hand across hundreds of namespaces.

What Is Kubernetes Security Scanning?

Kubernetes security scanning is the automated review of a Kubernetes cluster against security best practices and compliance requirements. It inventories your cluster resources and checks each one for misconfigurations, excessive permissions, insecure pod settings, missing network controls, and weak control plane configuration.

A thorough Kubernetes scan covers these areas:

• RBAC and identity Roles and ClusterRoles with wildcard verbs or resources, ServiceAccounts bound to cluster-admin, and risky permissions like the ability to create pods or read every secret.
• Pod and workload security Containers running as root or privileged, host namespace sharing, writable root filesystems, and missing security contexts that let a compromised pod escape to the node.
• Network policies Namespaces with no default-deny policy, so any pod can reach any other pod, and services exposed more broadly than they need to be.
• Secrets handling Secrets stored without encryption at rest, mounted where they are not needed, or exposed through over-broad RBAC.
• Control plane configuration Insecure flags on the API server, kubelet, etcd, the controller manager, and the scheduler, including anonymous auth, weak TLS, and missing audit logging.
• Compliance posture Whether your cluster meets the controls required by the CIS Kubernetes Benchmark, ISO 27001, PCI DSS, and other frameworks.

This sits alongside broader Cloud Security Posture Management (CSPM). A cluster rarely lives in isolation, so scanning the Kubernetes layer and the cloud account it runs in together gives you the full picture.

How to Run a Kubernetes Security Scan with Prowler Cloud

Here is the full process, start to finish. Prowler Cloud scans your cluster with a read-only ServiceAccount, so it can assess your configuration but never change anything. You can get your first results in minutes.

1. Create a free Prowler Cloud account Sign up at cloud.prowler.com. Prowler Cloud is free to try and needs no credit card. Once you are in, go to "Configuration," then "Providers," then "Add Provider" to start onboarding your cluster.
2. Add your Kubernetes cluster as a provider Choose "Add Provider" and select "Kubernetes." Enter the cluster context from your kubeconfig file and, optionally, a friendly alias. For Kubernetes, the account identifier in Prowler Cloud is the cluster name, so the alias is what helps you tell clusters apart in reports.
3. Provide your kubeconfig for authentication Paste the contents of your kubeconfig file into the "Kubeconfig content" field. By default that file lives at ~/.kube/config. Prowler Cloud uses it to authenticate to your cluster and read configuration. For a local or self-managed cluster, this is often all you need.
4. Set up read-only access for EKS, GKE, AKS, or external clusters For a managed or external cluster, first allow traffic from the Prowler Cloud IP address 52.48.254.174/32. Then apply the Prowler ServiceAccount, Role, and RoleBinding manifests from the kubernetes directory of the Prowler repository. These create a prowler-sa ServiceAccount with read-only permissions. Generate a ServiceAccount token, point your kubeconfig at it, and you are ready to connect.
5. Test the connection and run your first scan Back in Prowler Cloud, test the connection to confirm access, then launch the scan. Prowler checks your cluster across RBAC, the API server, the kubelet, etcd, the controller manager, the scheduler, and core workloads. There are no agents to install. First results appear in minutes.
6. Review findings and filter by compliance framework Open the findings dashboard, sort by severity, and filter by framework such as the CIS Kubernetes Benchmark, ISO 27001, PCI DSS, or the Prowler ThreatScore. Every finding includes the affected resource, its namespace and workload, and the risk it carries, so you can see exactly what is exposed before you fix anything.
7. Remediate the findings For each issue, Prowler Cloud shows the affected cluster resource and the fix. Use Lighthouse AI to generate remediation, whether that is a manifest or YAML change, an IaC update, a kubectl or CLI command, or guided manual steps. To automate it end to end, the Prowler plugin for Claude Code finds the misconfigurations, prioritizes them by blast radius across RBAC, workloads, and the control plane, opens the pull requests that fix them, and re-scans to confirm each one cleared.
8. Rescan and prove it Re-run the scan to confirm the issue is closed, capture before and after cluster posture, and export audit-ready evidence mapped to the CIS Kubernetes Benchmark, ISO 27001, and PCI DSS. The Prowler plugin for Claude Code keeps a versioned audit trail of every fix under .prowler/ in your repo, so you can show an assessor exactly what changed and when.
9. Track owners, SLAs, and recurring scans Assign owners, set SLAs, and manage exceptions for the findings that remain. Turn on scheduled scans so your cluster posture is checked continuously, or deploy Prowler as an in-cluster CronJob that scans on a schedule and pushes findings straight to Prowler Cloud. Route findings to Slack, Jira, email, or your SIEM so issues reach the right team within hours.

Automate Your Kubernetes SecOps Workflow with Claude Code

Detection is solved. The work that actually eats your team's time is the glue between a finding and a verified fix: pulling findings across clusters, prioritizing them, writing the change, opening the PR, and proving it cleared. The Prowler plugin for Claude Code automates that entire DART-P loop for you.

Install it from the Claude Code plugin marketplace:

/plugin marketplace add prowler-cloud/prowler
/plugin install prowler@prowler-plugins

The plugin needs a Prowler Cloud account and an API key from cloud.prowler.com/profile. Once it is connected, drive it with a high-level goal like "Harden my production Kubernetes cluster against the CIS Kubernetes Benchmark." The agent pulls findings across your connected clusters, prioritizes them by blast radius across RBAC, workloads, and the control plane, proposes fixes with exact commands and reversibility, opens pull requests, tracks progress in versioned reports under .prowler/, and re-scans to confirm each check cleared. Because it grounds every recommendation in Prowler's open-source check logic and Prowler Hub remediation, the work is auditable and reproducible.

Kubernetes Compliance Frameworks

Most teams run a Kubernetes security scan because an auditor or an internal standard is asking for evidence. Prowler maps your cluster findings to recognized frameworks automatically, so you can prove your posture instead of assembling spreadsheets the night before.

The CIS Kubernetes Benchmark is the gold standard for hardening clusters, and Prowler ships multiple versions of it so you can match the one your auditor expects. Prowler's checks also align with the hardening guidance in the NSA and CISA Kubernetes Hardening Guide. Need to cover the cloud account your cluster runs in too? See the guide to running an AWS security audit or browse the full list of frameworks in the Prowler documentation.

Frequently Asked Questions