A Kubernetes custom resource that stores shared configuration once and is then pointed to by multiple workloads. In identity and access terms, referenced CRDs reduce duplication, make policy reusable, and limit drift when many servers rely on the same control settings.
Expanded Definition
A referenced CRD is a Kubernetes custom resource that centralises configuration once and allows multiple workloads to point to that shared object. In NHI and access governance, the pattern is useful when service accounts, controllers, or agentic workloads need the same policy, secret reference, or trust settings without copying values into each deployment.
Definitions vary across vendors and platform teams, but the core idea is consistent: the CRD acts as a single source of truth, while each workload consumes it by reference. That makes referenced CRDs closely related to policy objects, identity bindings, and reusable control templates, but not identical to them. A referenced CRD may describe access scopes, rotation intervals, token audiences, or external identity mappings, depending on the platform design. For a broader NHI governance context, the Ultimate Guide to NHIs shows why shared identity controls matter when machine identities scale faster than human oversight. Kubernetes users should also understand the resource model in the Kubernetes custom resources documentation.
The most common misapplication is treating the referenced CRD as a static copy of policy, which occurs when teams update the parent object but fail to verify that consumers actually resolve the new reference.
Examples and Use Cases
Implementing referenced CRDs rigorously often introduces dependency management overhead, requiring organisations to weigh reuse and consistency against versioning and rollout complexity.
- A platform team defines one CRD for service account token audience settings, and several microservices reference it to keep authentication boundaries consistent.
- Security teams publish a CRD that holds secret rotation parameters, reducing drift across namespaces while supporting a shared control model discussed in the Ultimate Guide to NHIs.
- An internal operator references a trust-policy CRD to standardise which external systems may request access, aligning with least-privilege design in the NIST Cybersecurity Framework 2.0.
- Multiple agent workloads point to the same CRD for API key renewal intervals, which helps prevent each team from inventing its own credential lifecycle rules.
- An engineering organisation uses a referenced CRD to manage per-environment identity defaults, so development, staging, and production inherit common guardrails while still allowing approved exceptions.
In practice, this pattern is most valuable when the same NHI control must be applied across many workloads without duplicating YAML or diverging from the approved security baseline.
Why It Matters in NHI Security
Referenced CRDs matter because machine identity risk scales quickly when policy is copied instead of referenced. Shared configuration reduces drift, but only if teams understand exactly what the reference controls and who can change it. If the parent CRD is over-permissioned, every consumer inherits that weakness. If the reference is broken, workloads may silently fall back to insecure defaults or stale settings. That is especially important in environments where Ultimate Guide to NHIs data shows 97% of NHIs carry excessive privileges, which means control reuse can amplify mistakes just as quickly as it can reduce them.
Good governance also depends on change visibility. The NIST Cybersecurity Framework 2.0 emphasises asset and access management, and referenced CRDs are a practical enforcement point for both in Kubernetes-native estates. They become especially important when a shared identity or policy object is used across clusters, namespaces, or automation pipelines. Organisations typically encounter privilege escalation, service disruption, or compliance drift only after a misconfigured rollout or incident review, at which point referenced CRDs become operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Referenced CRDs centralize reusable NHI controls and reduce configuration drift. |
| NIST CSF 2.0 | PR.AC-1 | Shared identity configuration supports controlled access to systems and services. |
| NIST Zero Trust (SP 800-207) | SP 5.2 | Referenced policy objects help apply consistent trust decisions across workloads. |
| NIST SP 800-63 | AAL2 | Credential and authenticator requirements map to reusable identity settings in workload policy. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agentic workloads often consume shared policy and tool-access settings through references. |
Bind workload authentication settings to approved shared controls and verify assurance levels remain consistent.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
