Custom Resource Definitions are targeted through overly broad permissions, malicious or buggy controllers, insecure admission paths, and supply-chain abuse of the custom resource lifecycle. Attackers may create privileged resources, alter workloads, or persist through controllers that watch the definition. Defenders should restrict who can create or update CRDs, review controller permissions, and validate schema and reconciliation logic.
What attacks target CRDs through Kubernetes control plane paths?
CRDs are not usually attacked as standalone objects, they are attacked as part of the control plane and the custom controller path around them. The common pattern is to abuse permissions, registration logic, reconciliation loops, or admission handling so an attacker can create, mutate, or retain privileged state through the CRD lifecycle.
That means the real question is not only whether the CRD exists, but who can define it, who can write to it, and what downstream workloads or controllers trust it.
How overbroad access and controller trust become the attack surface
One major attack path is excessive permission around CRD creation, update, or use. If a user, pipeline, or controller can write custom resource broadly, they may be able to trigger privileged behavior, alter workload configuration, or place objects into a state that the operator later reconciles into something more powerful than intended.
Another common path is controller abuse. A custom controller often runs with higher privileges than the users who create the custom resources it watches. If the controller accepts untrusted fields, mishandles defaults, or fails open on validation, the attacker can use the controller’s authority to change cluster state indirectly. The Kubernetes Security Guide is the right place to anchor this thinking because CRD abuse is usually a control-plane and reconciliation problem, not just an object-level permissions problem.
Why admission, schema, and supply chain weaknesses matter
CRD attacks also target the admission and validation path. If schema constraints are weak, if webhook logic is bypassable, or if a validating admission policy is missing, malicious payloads can slip through and later be acted on by controllers or operators. In practice, the danger is often delayed execution, where the object looks harmless at write time but becomes dangerous when a controller reconciles it.
Supply-chain abuse matters because the controller, operator, or admission component may itself be the trust anchor. A compromised controller image, a malicious dependency, or an unsafe update to the operator can turn CRD traffic into a persistence mechanism. That is why the attack surface includes both the definition and the code that interprets it. The State of NHI & AI Agent Breach Report 2026 is useful here as a broader pattern reference for how abused control relationships and delegated authority become persistence and lateral movement paths.
How defenders should think about detection and containment
Defenders should watch for unusual CRD creation, changes to CRD schemas, unexpected controller role bindings, and custom resources that cause privileged side effects. A mature review process looks at who can define the CRD, who can write instances of it, what the reconciliation logic can touch, and whether the controller’s permissions are broader than the business need.
For external authority, the attack patterns map well to the OWASP API Security Top 10 when the custom resource surface behaves like an internal API, especially broken authorization and insecure handling of resource operations. The cluster-level threat picture is also well covered by CISA cyber threat advisories, which is a good place to track exploitation trends and defensive guidance that affect Kubernetes-adjacent exposure.
Risk and Threat Considerations
CRDs concentrate trust in the objects that describe desired state, so a compromise of the CRD path can turn ordinary configuration into privilege, persistence, or workload manipulation. The highest-risk cases are the ones where custom resources are accepted from many writers but reconciled by one highly privileged controller.
Failure mechanism: Weak authorization, unsafe validation, or compromised controller logic lets an attacker inject or modify custom resources that the controller then translates into privileged cluster actions.
Impact: The attacker may create unauthorized workloads, alter running services, persist through reconciliation, or expand control from a low-privilege write path into cluster-wide influence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | CRD abuse often hinges on unauthorized use of privileged object operations. |
| API1 — Broken Object Level Authorization | Custom resources can expose object-level access gaps through unsafe read/write paths. | |
| Recommendation — Enforce function-level authorization on CRD and controller operations. Validate object-level authorization for every custom resource request. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Controllers and writers should have only the permissions needed for CRD handling. |
| CM-5 — Access Restrictions for Change | CRD changes and controller updates are change-controlled security boundaries. | |
| Recommendation — Restrict CRD writers and controller permissions to least privilege. Control and approve CRD and controller changes before deployment. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Managing who can create or update CRDs is a core access-control task. |
| Recommendation — Limit and review who can create, update, or administer CRDs. | ||
Practitioner Guidance
What to verify: Separate permission to define a CRD from permission to create custom resources, and separately review who can update the controller that consumes them. If those three controls are not independently restricted, the attack surface is larger than it appears.
What good looks like: The CRD schema is tight, admission rejects unexpected fields, controller permissions are minimal, and reconciliation only touches the objects and namespaces it truly needs. If the controller can mutate cluster-wide resources, treat that as a privileged security boundary rather than a normal application setting.
Practitioner takeaway: CRD security is really about preventing untrusted state from becoming trusted action, so the control objective is to bound who can write the object, what the controller can do with it, and how quickly abuse can be detected.