Why do in-cluster scanners increase container security risk?

Why This Matters for Security Teams

In-cluster scanners are attractive because they sit close to the workloads they inspect, but that proximity creates a security tradeoff. The scanner often needs broad read access to Kubernetes objects, node metadata, and registry authentication material so it can identify vulnerable images and misconfigurations. That means the tool is not just observing the environment, it is operating inside the trust boundary it is meant to protect.

Security teams should treat this as a control design issue, not just a deployment preference. If a scanner has access to secrets, service account tokens, or ImagePullSecrets, compromise of the scanner can expose paths to image registries and other sensitive systems. This is why NIST Cybersecurity Framework 2.0 places emphasis on asset visibility, access control, and risk management across the full environment. The operational mistake is assuming a security tool is harmless simply because it is defensive.

In practice, many security teams discover excessive scanner privilege only after an incident review shows the scanner had become a pivot point rather than a control.

How It Works in Practice

An in-cluster scanner is usually deployed as a Kubernetes workload with service account permissions that let it enumerate namespaces, inspect pods, read image references, and sometimes access cluster secrets so it can validate registry access and image provenance. In some designs it also reaches external registries to pull manifests, query metadata, or correlate vulnerabilities against running images. That makes it operationally useful, but it also expands the scanner’s attack surface.

The risk increases because the scanner often combines multiple trust functions in one component: discovery, authentication, collection, and reporting. If one of those functions is compromised, the attacker may inherit the others. Current guidance suggests splitting duties where possible and limiting secret exposure to the minimum required for inspection. The most common hardening steps are:

• Use read-only, narrowly scoped service accounts.
• Avoid mounting registry credentials unless the scanner truly needs them.
• Store and rotate secrets outside the scanner pod where practical.
• Prefer short-lived tokens and workload identity patterns over static credentials.
• Log scanner access to Kubernetes resources and registry endpoints for review.

This aligns with the control intent of OWASP Kubernetes Top Ten, especially around over-privileged workloads and weak secret handling, and with the CISA Kubernetes hardening guidance, which stresses minimizing trust inside the cluster. The practical lesson is that a scanner should be treated like any other privileged workload, subject to the same segmentation and credential governance as an admin service.

These controls tend to break down when scanners are deployed as a single shared cluster-wide service because teams grant broad permissions to avoid breaking image coverage across namespaces and clusters.

Common Variations and Edge Cases

Tighter scanner isolation often increases deployment and maintenance overhead, so organisations must balance visibility against credential exposure. That tradeoff becomes sharper in multi-cluster platforms, air-gapped environments, and service-mesh-heavy estates where inspection coverage depends on broad access paths.

There is no universal standard for exactly how much access an in-cluster scanner should have. Best practice is evolving toward delegated, least-privilege designs that separate vulnerability discovery from secret retrieval and registry authentication. Where scanners must authenticate to private registries, teams should consider whether the credentials can be scoped to read-only image access, constrained by namespace, repository, or environment. The same logic applies to NHI governance: if the scanner workload itself has a workload identity, that identity should be treated as a managed Non-Human Identity with ownership, rotation, and revocation controls.

Edge cases also appear in ephemeral CI/CD clusters and short-lived test environments. In those cases, the scanner may be allowed slightly broader access for operational simplicity, but that exception should be time-bound and documented. For cloud-native environments, the safest pattern is usually to separate scanning from privileged reconciliation and to validate output against the least amount of cluster state required. The CIS Kubernetes Benchmark is a useful reference point for hardening decisions, especially where the scanner itself becomes part of the attack surface.

In practice, the risk is highest when convenience-driven permissions persist long after the initial rollout and no one revisits the scanner’s access model.

Related resources from NHI Mgmt Group

• Why does GenAI adoption increase security risk as usage grows?
• Why does vibe coding increase application security risk?
• Why do AI-generated code changes increase application security risk?
• Why do oversized request bodies create a security risk in container platforms?