Teams should treat controller-created custom resources as high-trust automation and lock down who can create or mutate the upstream definitions. Use explicit RBAC, restrict cluster-admin privileges, and review the controller’s reconciliation boundaries so users cannot coerce privileged actions. In Kubernetes, a controller can become a confused deputy if it accepts attacker-controlled input and turns it into workload changes.
Controllers, reconciliation, and the trust boundary they create
Kubernetes controllers are not passive background services. When they create custom resources on behalf of users, they are acting with delegated authority, so the security question becomes who can influence that authority and how far the controller can be induced to act. The core issue is not the presence of automation itself, but whether the automation is allowed to turn user input into privileged cluster state.
That trust boundary is easy to underestimate because controller logic often looks like ordinary orchestration. In practice, the controller may be the only component that can validate, enrich, or materialise a request, which makes it a high-value path for privilege amplification if upstream definitions are writable too broadly. The most relevant external reference for this pattern is the OWASP Non-Human Identity Top 10, because it frames machine-mediated authority as an identity and access problem rather than a pure application problem. In practice, many teams notice the weakness only after reconciliation has already converted a harmless-looking request into a cluster-wide permission issue.
How to think about controller-secured custom resources in day-to-day operations
The practical security model starts with separation of concerns. Users should be able to request outcomes, but not directly shape the controller’s privileged behaviour beyond the narrow fields the controller is intended to consume. That means upstream custom resource definitions, validation, and admission boundaries matter as much as the controller deployment itself. If a controller can create child objects, write secrets, or assign service accounts, every input path into that controller becomes part of the attack surface.
A useful way to assess the design is to ask three questions: what input can a user control, what action does the controller take with that input, and what privilege does the controller hold while acting? If those three layers are too loosely coupled, a user can trigger actions the controller was never meant to expose. This is especially important where the controller runs with broad namespace or cluster permissions, because reconciliation then becomes a privilege translation layer rather than a narrow workflow engine.
- Limit who can create or edit the custom resource definitions that the controller consumes.
- Keep controller permissions narrower than the total capability of the cluster objects it may create.
- Validate which fields are user-supplied versus controller-owned, and reject attempts to influence privileged parameters.
- Review whether the controller can cross namespaces, bind roles, mount secrets, or create follow-on objects that expand impact.
Well-run teams also distinguish between a controller that reflects user intent and one that performs security-sensitive actions on the user’s behalf. The latter needs stronger approval, tighter input validation, and more explicit ownership because it can become a delegated trust broker inside the cluster. This guidance breaks down when the controller’s privileged behaviour is intentionally broad and the organisation has not documented which actions are meant to be user-triggerable at all.
Where the edge cases usually appear
Tighter controller governance often increases operational overhead, requiring organisations to balance developer flexibility against the risk of hidden privilege transfer. That tradeoff becomes sharper in multi-tenant clusters, platform teams that delegate workload creation, and controllers that generate secondary resources such as Roles, Secrets, or ingress configuration.
One common edge case is when the controller is safe in isolation but unsafe in combination with permissive RBAC. Another is when users cannot modify the controller directly, but can still feed it object names, labels, annotations, or references that influence downstream creation. Guidance is not fully unanimous on how much logic belongs in admission control versus the controller itself, but there is broad agreement that trust-sensitive fields should be owned by the controller, not the requester.
Another subtle case is reconciliation drift. If the controller continuously restores objects to a privileged state, a brief misconfiguration can become persistent exposure. Teams should therefore treat the controller’s permissions, object templates, and reconciliation defaults as a single control surface rather than as separate concerns. The safest designs are the ones where users can request work without being able to steer the controller into unrelated privilege-bearing actions.
Risk and Threat Considerations
Kubernetes controllers that create custom resources on behalf of users can create confused-deputy exposure, privilege escalation paths, and tenant-isolation failures. The main risk is that attacker-controlled input is converted into actions performed with the controller’s higher privileges, which can make an otherwise ordinary workflow into a control-plane abuse path.
Failure mechanism: The weakness appears when user-writable fields, broad RBAC, or unsafe reconciliation logic let the controller act on untrusted inputs without a strict boundary between request data and privileged action. The controller then becomes a trusted intermediary that can be induced to create, modify, bind, or propagate objects beyond the requester’s intended scope.
Impact: The result can include unauthorized workload changes, secret exposure, role or namespace abuse, and persistence of misconfigurations through reconciliation. In a multi-tenant environment, that can also undermine isolation by letting one user influence resources that affect other users or the cluster as a whole.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | Controller-created resources act as delegated non-human authority. |
| NHI-03 — Secrets and Credential Management | Controllers often create or handle privileged tokens and service credentials. | |
| NHI-06 — Least Privilege and Just-in-Time Access | The controller's own permissions should stay narrower than the actions it can trigger. | |
| Recommendation — Inventory controller-owned identities and bound resources, then assign explicit ownership for each trust path. Restrict controller access to secrets and rotate any credential it can mint or mount. Apply least privilege to controller service accounts and remove standing cluster-wide rights. | ||
| CIS Controls v8 | 6 — Access Control Management | This is fundamentally about controlling who can create or mutate privileged Kubernetes inputs. |
| 8 — Audit Log Management | Controller-triggered privilege changes need traceable review and detection. | |
| Recommendation — Tighten access to custom resources and administrative bindings that influence controller actions. Log controller reconciliations and review changes that create or alter privileged objects. | ||
| MITRE ATT&CK | T1611 — Escape to Host | A privileged controller can be abused to break intended isolation and reach broader system impact. |
| T1610 — Deploy Container | Controllers may be coerced into creating workload objects that support attacker execution. | |
| Recommendation — Hunt for controller abuse patterns that let attacker-controlled inputs expand beyond the intended namespace. Detect unexpected workload creation driven by custom resources and block unapproved pod templates. | ||
Practitioner Guidance
What to prioritise: Classify every field the controller consumes as either requester-controlled or controller-owned, then treat any field that can influence object identity, privilege, or cross-namespace behaviour as security-sensitive.
Decision rule: If a user can change what the controller creates, who it creates it for, or which permissions the created object inherits, the design needs a tighter boundary than ordinary RBAC alone can provide.
What to verify: Confirm that the controller cannot be steered into creating secondary resources that expand access, and verify that reconciliation does not restore unsafe states after an operator has corrected them.
Practitioner takeaway: The real control objective is not just limiting who can talk to the controller, but preventing user input from becoming a privileged action through the controller’s reconciliation loop.
Related resources from NHI Mgmt Group
- How should security teams secure local AI agent hubs that expose credentials and act on behalf of users?
- How should security teams authorize API requests made by applications on behalf of users?
- How should security teams govern Kubernetes access without giving users direct cluster credentials?
- How should security teams secure FastAPI endpoints without writing custom auth logic?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
