Mutable CRDs can let a less-privileged actor change the blueprint that a more-privileged controller trusts. The controller then reconciles attacker-supplied values as if they were legitimate, which can produce malicious workloads, altered images, or unintended access paths. The risk is highest when reconciliation is delayed, permissions are broad, and the controller does not continuously validate the source of truth.
How Mutable CRDs Shift Trust from Policy to Data
Mutable custom resource definitions create a trust boundary problem because Kubernetes controllers usually treat the resource as the authoritative specification for what should exist. When a lower-privileged actor can change that specification after a controller has been granted authority to act on it, the controller may enforce attacker-influenced instructions without realising the source of those instructions has become unsafe. That is the core confused deputy pattern: the deputy has the privilege, but the attacker controls the trigger.
For Kubernetes teams, the issue is not just whether the CRD schema is valid. A valid object can still be dangerous if it changes the intended deployment, image, configuration, or access context in ways the controller will faithfully apply. The NIST Cybersecurity Framework 2.0 is useful here because the problem spans governance, access control, and change oversight rather than a single technical misconfiguration. In practice, many platform teams discover this only after a controller has already reconciled an object that was altered between approval and execution.
Where the Confused Deputy Pattern Appears in Reconciliation
Kubernetes reconciliation amplifies the risk because controllers operate asynchronously. A user may create or edit a custom resource, then a controller later observes that object and acts on it using its own service account and cluster privileges. If the resource is mutable, the controller may be working from a moving target rather than a stable request. That is especially important when the controller performs privileged follow-on actions such as creating pods, mounting secrets, selecting images, or generating subordinate resources.
The practical failure sequence usually looks like this:
- A less-privileged actor can update a CRD instance after initial submission.
- The controller trusts the object state at reconciliation time, not the origin of the change.
- The controller executes actions with broader permissions than the actor holds.
- Attacker-controlled fields are translated into real cluster effects.
The risk increases when reconciliation is delayed, because the longer the gap, the more opportunity there is for a benign-looking object to be modified before the controller consumes it. It also rises when the controller does not bind its actions to an immutable, signed, or otherwise attested source of truth. In those cases, the controller becomes a privilege amplifier for whoever can edit the resource. This guidance breaks down when the controller itself has no meaningful authority beyond the submitting user, because then the deputy has little extra privilege to misuse.
When Mutability Is Acceptable and When It Becomes a Trap
Tighter CRD mutability often improves workflow flexibility, but it also increases the burden of proving that later edits are still safe. The tradeoff is between operational convenience and the integrity of the controller’s decision inputs.
Not every mutable CRD is equally risky. The pattern is most dangerous when the object contains fields that directly influence privileged actions, such as image references, mount targets, namespace selection, approval state, or generated access relationships. It is less severe when mutability is limited to non-authoritative metadata that the controller does not use for security-sensitive decisions. There is no universal consensus that every mutable CRD is unsafe; the real question is whether the mutable field can alter what a more privileged component will do.
Teams also need to separate editing rights from execution rights. A user may be allowed to request change without being allowed to steer privileged automation. If that separation is absent, the CRD becomes a policy input that can be rewritten after policy review, which is exactly where the confused deputy risk emerges. Where the design cannot enforce that separation, the safer posture is to narrow update permissions, freeze security-sensitive fields after creation, or require the controller to revalidate every field it consumes before acting. The edge case is high-churn environments where rapid updates are normal; in those settings, mutability may be necessary, but only with very tight field-level trust checks.
Risk and Threat Considerations
Mutable CRDs can expose privileged automation to request tampering, privilege misuse, and indirect workload injection. The attacker does not need the controller’s permissions, only a way to influence the object the controller trusts.
Failure mechanism: A controller reads a mutable resource as if it were an approved instruction set, then reconciles attacker-edited fields using its own higher privilege. The weakness is the trust handoff between submission and execution, especially when state changes are not revalidated at consumption time.
Impact: The result can be malicious workloads, altered execution context, unintended secret exposure, or creation of access paths that the lower-privileged actor could not establish directly. At scale, the same defect can turn one writable custom object into a cluster-wide privilege escalation pathway.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1078 — Valid Accounts | CRD tampering can steer privileged controller actions through trusted execution paths. |
| Recommendation — Map controller abuse paths to T1078 and tighten trust on inputs that trigger privileged actions. | ||
| CIS Controls v8 | 6 — Access Control Management | The risk depends on who can modify security-sensitive CRD fields and when. |
| Recommendation — Restrict write access to CRD fields that influence privileged reconciliation. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Confused deputy risk emerges when edit rights and execution rights are not separated. |
| PR.DS — Data Security | Mutable CRDs can turn control data into an unsafe instruction source. | |
| DE.CM — Continuous Monitoring | Delayed reconciliation creates a detection gap for object tampering. | |
| Recommendation — Separate editing authority from controller execution authority for mutable custom resources. Protect controller inputs so edited resource state cannot drive unsafe privileged actions. Monitor CRD changes and reconcile against expected state before executing privileged actions. | ||
Practitioner Guidance
What to verify: Confirm which CRD fields actually drive privileged controller behaviour, and treat those fields as security-sensitive inputs. If a field can change scheduling, images, mounts, identity bindings, or generated resources, it needs stricter handling than ordinary configuration.
Decision rule: If a user can edit the object after approval and the controller later acts on that edited value, assume confused deputy exposure unless the controller rechecks authorisation or the field is immutable.
What good looks like: The controller only trusts stable, well-bounded inputs, and any mutable field that affects privileged action is either locked after creation or validated again at reconciliation time before use.
Practitioner takeaway: The safest design is not “allow edits and trust the controller,” but “allow only the edits the controller can safely re-interpret without inheriting attacker intent.”
