Running a security tool inside the same Kubernetes or cloud environment as the workloads it tests. This improves visibility into private services and internal endpoints while reducing the blind spots that can appear when a scanner operates only from outside the network boundary.
Expanded Definition
In-cluster deployment describes a tool that runs within the same Kubernetes cluster, namespace, or tightly scoped cloud environment as the assets it inspects. For security testing, this placement changes the trust boundary: the tool can reach internal services, service meshes, and private APIs that may not be exposed outside the environment. In practice, the term is used most often for scanners, policy agents, observability components, and compliance checks that need local network context rather than broad internet reachability.
At NHI Management Group, this term is best understood as an architectural choice rather than a product category. The same deployment pattern can improve fidelity, but it also expands the tool’s access to workloads, secrets, and cluster metadata. That makes identity scoping, workload permissions, and runtime isolation part of the design decision. This aligns with the governance intent expressed in the NIST Cybersecurity Framework 2.0, where visibility and access control must be balanced against operational risk. The most common misapplication is treating in-cluster deployment as automatically safer, which occurs when teams ignore the added blast radius of a compromised scanner or over-privileged service account.
Examples and Use Cases
Implementing in-cluster deployment rigorously often introduces credential-scoping and operational-isolation overhead, requiring organisations to weigh deeper inspection coverage against the cost of managing another privileged workload inside production.
- A Kubernetes security scanner runs as a pod in each cluster so it can inspect private service-to-service traffic and internal endpoints that an external scanner cannot reach.
- A policy validation agent is deployed in-cluster to evaluate admission requests locally, reducing latency and preserving context for namespace-specific rules.
- A compliance monitoring tool uses an in-cluster service account to inventory workloads, ConfigMaps, and secrets relationships without exposing cluster APIs publicly.
- A runtime protection agent is placed alongside application pods to observe east-west traffic and detect anomalous access patterns inside segmented namespaces.
- An internal vulnerability assessment job is scheduled inside a staging cluster so it can test private dependencies and non-routable management services before release.
This pattern is common in cloud-native operations, but the implementation details vary by platform and policy model. Guidance from groups such as NIST Cybersecurity Framework 2.0 helps teams frame the control objective, while the exact Kubernetes mechanics depend on how cluster access, namespaces, and workload identities are governed.
Why It Matters for Security Teams
Security teams use in-cluster deployment when external testing leaves gaps in coverage, especially for private services, internal-only routes, and controls that depend on cluster-local context. The benefit is better signal: fewer false negatives caused by network boundaries. The cost is that the deployed tool becomes part of the trusted computing surface, so its service account, RBAC bindings, secret access, and update path all need deliberate hardening.
For identity and access governance, the key concern is not only whether the tool can see workloads, but what it can do once inside the cluster. If an attacker compromises the in-cluster component, the environment may inherit a new escalation path into secrets, tokens, and administrative APIs. This is why practitioners should treat workload identity and privilege containment as first-order controls rather than deployment details. Organisational teams typically encounter the consequences only after an internal scan agent is abused to enumerate sensitive services or pivot into adjacent namespaces, at which point in-cluster deployment becomes operationally unavoidable to review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | In-cluster tools depend on tightly scoped access and least privilege. |
| NIST Zero Trust (SP 800-207) | SC-7 | Cluster-local placement still needs explicit trust boundaries and segmentation. |
| NIST SP 800-63 | AAL2 | Workload identities and credentials should meet appropriate assurance for privileged access. |
| OWASP Non-Human Identity Top 10 | In-cluster deployments often rely on non-human identities and token-based access. | |
| NIST AI RMF | If the in-cluster tool is AI-enabled, governance must cover deployment context and risk. |
Use strong authentication and controlled credential issuance for the tool’s administrative access.
Related resources from NHI Mgmt Group
- What are the main reasons AI agents struggle to achieve enterprise-scale deployment?
- When should organizations reconsider the deployment of AI agents?
- Why is it necessary to address authorization challenges in AI agent deployment?
- What is the difference between private IGA deployment and on-premises identity governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
