A Reference Grant is a Kubernetes permission object that allows a resource in one namespace to reference another resource in a different namespace. It is commonly used to control access to plugins, routes, services, or secrets without collapsing namespace boundaries. This makes delegation explicit and reduces the risk of broad, implicit trust.
Expanded Definition
A Reference Grant is a Kubernetes permission object that makes cross-namespace references explicit instead of relying on broad namespace reach. In NHI and platform engineering terms, it is a guardrail for delegation: one namespace can reference another resource only when the owning namespace has intentionally allowed that relationship.
That matters because namespace boundaries are often treated as security boundaries, but many workloads need controlled exceptions for routes, plugins, services, or secrets. Reference Grants preserve separation of duties by letting teams expose only the exact references they intend, rather than expanding access through shared roles or loosely scoped service accounts. This pattern aligns with NIST Cybersecurity Framework 2.0 principles of controlled access and with Zero Trust thinking, where trust is granted per relationship, not per network location.
Definitions vary across vendors and platform implementations, but the operational idea is consistent: a reference is not an entitlement unless the owner says so. The most common misapplication is assuming a namespace policy alone is enough, which occurs when teams permit cross-namespace access through indirect RBAC patterns and then lose visibility into who can bind to what.
Examples and Use Cases
Implementing Reference Grants rigorously often introduces extra coordination between application teams and platform owners, requiring organisations to weigh safer delegation against slower delivery when new cross-namespace dependencies appear.
- A gateway namespace is allowed to reference a shared certificate secret in another namespace, but only for a specific route object and only after explicit approval.
- A platform team enables a plugin namespace to point to a central service without giving that namespace broad read access to every service object in the cluster.
- A multi-tenant cluster uses reference control to let one team consume a shared backend while preventing lateral discovery of unrelated resources.
- An internal API deployment is granted access to a secret owned by a security namespace, reducing the need to duplicate credentials across environments and supporting the governance themes described in Ultimate Guide to NHIs.
- A cluster operator pairs reference permissions with review workflows so that every new cross-namespace link is visible during change management and audit.
These patterns are easier to reason about when the platform team treats references as explicit objects and validates them against the same standards used for identity and access design. That approach is consistent with NIST Cybersecurity Framework 2.0 guidance on access governance.
Why It Matters in NHI Security
Reference Grants matter because cross-namespace access is one of the places where NHI sprawl becomes invisible. A service account, controller, or agent may appear confined to one namespace while still reaching sensitive resources elsewhere through an allowed reference. That weakens least privilege and can turn a small configuration error into a broad trust expansion.
This is especially important in clusters where secrets, service endpoints, and agent tools are shared across teams. NHIMG research shows that 97% of NHIs carry excessive privileges, and that 79% of organisations have experienced secrets leaks, with 77% of those incidents causing tangible damage, which makes controlled delegation more than a design preference. Used well, Reference Grants reduce accidental overexposure and support auditable trust boundaries across automated workloads. Used poorly, they become another hidden path to privileged access.
Organisations typically encounter the operational impact only after an unexpected cross-namespace dependency is abused, at which point reference governance becomes 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, CSA MAESTRO and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 | Cross-namespace delegation maps to controlling NHI authorization scope and trust boundaries. |
| NIST CSF 2.0 | PR.AC-4 | Reference Grants enforce least privilege by limiting who can reference shared resources. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires explicit, per-relationship authorization rather than implicit namespace trust. | |
| CSA MAESTRO | Agentic workloads need tightly scoped tool and resource delegation across namespaces. | |
| OWASP Agentic AI Top 10 | Agent tool and resource access should be explicitly authorized, not inferred from cluster context. |
Review reference permissions as part of access governance and remove any unneeded cross-namespace links.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
