A Non-Resource URL is an API endpoint path that is not tied to a named resource object. In Kubernetes, it is used for paths such as health checks or metadata endpoints, and access is controlled separately from resource verbs through authorisation rules.
What Non-Resource URL Means in Kubernetes
A Non-Resource URL is a request path that is authorised directly as a URL, rather than as a verb on an API object. In Kubernetes, this is how endpoints such as health checks and metadata paths are handled when they are not part of the normal resource model.
The distinction matters because Kubernetes treats resource access and non-resource access as different decision paths. A policy that allows reading Pods, for example, does not automatically allow calling a non-resource endpoint such as /healthz or /metrics.
How Non-Resource URLs Fit the Kubernetes Authorisation Model
Non-resource URLs exist because clusters expose some operational endpoints that are useful for monitoring, liveness, diagnostics, and control-plane integration, but do not map cleanly to Kubernetes objects. These paths are evaluated separately from resource verbs like get, list, create, update, or delete.
That separation is important for least privilege. A service account, user, or component may need access to a specific endpoint for observability or integration without being granted broad object access across the API.
It also means operators should think in terms of endpoint scope, not just object scope. In practice, the question is not only “which resources can this principal read?” but also “which API paths can this principal reach?”
Why Non-Resource URLs Are Operationally Sensitive
Even when a path is not backed by a Kubernetes object, it can still reveal useful operational detail. Health, readiness, version, discovery, and metadata endpoints can expose information that helps defenders run the platform, but that can also help an attacker map the cluster if exposed too broadly.
For that reason, non-resource URL rules should be treated as part of the attack surface review, especially when endpoints are reachable over the network or exposed through ingress, proxies, or management interfaces. OWASP API Security Top 10 is a useful companion reference for thinking about authorisation failures, overexposure, and API-specific abuse paths.
In Kubernetes environments, the operational risk is usually not that the endpoint itself is complex, but that it is easy to overlook because it sits outside the normal resource permissions model.
Using Non-Resource URLs Correctly in Access Policy Design
Practitioners should define non-resource URL permissions narrowly and intentionally. The safest pattern is to grant only the exact path or path prefix required for the workload, controller, or operator function, and to avoid broad URL wildcards unless there is a clear operational reason.
When you review Kubernetes access, check both object permissions and non-resource URL permissions in the same audit pass. RFC 8707: Resource Indicators for OAuth 2.0 is a useful conceptual reference for audience scoping, because it reinforces the broader principle that access should be tied to the intended target, not granted generically.
If a cluster exposes custom operational endpoints, document them as part of the platform security model and review them alongside RBAC, network exposure, and monitoring coverage. If an endpoint is not needed, remove or disable it rather than relying on policy alone to reduce exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, 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 ASVS | V8 — Authorization | Non-resource URL access is an authorization decision distinct from object verbs. |
| Recommendation — Define explicit authorization checks for each non-resource API path and review them separately from object access. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Kubernetes must enforce path-level access decisions for non-resource URLs. |
| AC-6 — Least Privilege | Non-resource URL permissions should be granted only to the exact operational paths required. | |
| Recommendation — Enforce path-specific access decisions for non-resource endpoints instead of relying on broad API access. Limit non-resource URL permissions to the minimum set of paths needed for the workload or operator. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Path-based API access is part of managing and reviewing effective access scope. |
| Recommendation — Review non-resource URL permissions as part of access control management and remove unnecessary endpoint access. | ||