I'm a pentester learning Kubernetes and keep seeing tools like kube-bench, Trivy, Falco, and admission policies. What does each layer actually do, and how can I check that the controls fire rather than just assuming they're working?
Why is there so much scanning in Kubernetes, and how do you test the guardrails?
Asked by
_Mivor+3e
Answers
They're looking at different things. kube-bench checks cluster configuration against benchmark recommendations, while Trivy can find known vulnerabilities and configuration issues. Falco watches runtime activity for suspicious behavior, and admission policies can reject resources before they're accepted by the API.
A clean scan doesn't prove an admission rule will deny a bad manifest, or that a runtime alert will reach anyone. Test each control against the outcome you expect: a finding, a denial, or an alert.
Reply to this answer
For admission policies, start with test manifests rather than a live cluster. Kyverno has kyverno test, and Gatekeeper has gator test. Give them examples that should pass and examples that should fail, then run those tests when policies change.
That checks the policy logic, but you can also try a controlled request in a test cluster to check the policy is installed and enforcing as expected.
Reply to this answer
For Falco, there's an event-generator that can trigger activity matching rules, so you can check whether an alert appears. Run it in a test environment and check both the rule output and wherever alerts are supposed to end up. A detection that fires locally but never reaches the alert destination is only part of the chain.
Reply to this answer
Don't let the scanners replace the pentest. The usual fundamentals still apply, but Kubernetes knowledge helps you find the relevant paths. Look at API access, permissions, and what a workload can reach or do with its credentials. Then exercise the guardrails around the paths that matter, within an agreed scope.
Tools such as Stratus Red Team can help simulate attack techniques, alongside deliberate attempts to violate policies or trigger detections.
Reply to this answer
Take benchmark results with a grain of salt for your distribution. A check written for one cluster setup may not fit another, particularly a managed service. That can mean false positives or missed issues, so investigate the actual configuration and what the check assumes before treating the report as proof either way.
Reply to this answer
Add your answer
Answers are reviewed before publication.
_Mivor+3e:
So the offline tests check the rule itself, while the cluster test checks the deployed setup too?
Rellva-5t:
Exactly. A passing policy test alone won't tell you whether that policy is active in the cluster you're checking.