What do teams get wrong about testing Kubernetes permissions with custom resources?

Teams often assume RBAC testing only needs to cover native Kubernetes objects. In practice, custom resources can introduce new authorization targets that still use the same RBAC machinery. If security tools do not understand those dynamically added resources, they may miss allowed actions, escalation paths, or gaps between policy intent and actual enforcement.

Why Kubernetes permission tests break once custom resources enter the picture

The common mistake is treating Kubernetes authorization as if it only applies cleanly to built-in objects such as Pods, Deployments, and Secrets. Custom resources are first-class API objects too, so permission testing has to follow the actual resource types and verbs the cluster exposes. If your tests only cover the native surface, you can miss policy gaps that appear the moment an operator, extension, or admission flow adds new objects.

That matters because custom resources often become the real control point for higher-level platform behavior. A team may think it has proven least privilege, but the policy was only exercised against the default API set. Once a custom resource definition is installed, the same RBAC machinery can authorize actions on that new object, and those decisions may differ from what the test suite assumed.

Well-run tests therefore validate permissions against the cluster’s live API discovery, not a static list of canonical Kubernetes kinds. That includes checking whether tools can enumerate custom resources, whether verbs are allowed or denied as intended, and whether policy engines understand the resource names and API groups that custom controllers introduce.

What custom resources change about authorization and escalation paths

Custom resources do not create a separate security model, but they do change the authorization surface. A role can be harmless against native objects and still be overly broad once a custom API exposes sensitive operations, especially if the resource represents privileged infrastructure actions, tenant data, or controller inputs that trigger downstream automation.

This is where escalation paths get missed. If a subject can create or patch a custom resource that a controller later reconciles into a privileged action, the effective permission is larger than the RBAC rule appears on paper. The test has to prove both the direct API permission and the indirect effect of that permission on the controller or operator that consumes the resource.

Security testing should also distinguish between authorization models and implementation reality. RBAC may be the enforcement layer, but custom resources can still widen the set of objects that RBAC must govern. For broader privilege reduction work, teams often pair that view with the Cloud PAM and CIEM Guide and the Privileged Access Management Guide to keep effective permissions aligned with intended access.

How to test permissions without missing custom-resource gaps

The practical mistake is using one test fixture for “Kubernetes access” and assuming it covers every resource kind. A stronger approach is to pull the live discovery document, expand tests across the actual API groups, and run positive and negative checks for each relevant verb on both native and custom objects. That is especially important for create, patch, update, and delete, because those verbs often drive controller behavior rather than simple read access.

Teams should also verify how tooling interprets dynamic resources. Some scanners, policy tests, and review scripts only understand built-in kinds or a fixed schema set, so they report a clean result even when custom resources are overexposed. The test is not complete until it confirms the toolchain can see the same authorization surface that the cluster will enforce.

When custom resources are tied to operators, admission controllers, or automation pipelines, test the end-to-end effect of the permission, not just the API call. A denied direct action may still be shadowed by an allowed indirect path through a controller, and that is often where escalation or policy drift appears first. For permission discovery and runtime visibility, the Identity Security Posture Management Guide is useful as a companion view, because it emphasizes finding the permissions that actually exist, not only the ones people believe exist.

Risk and Threat Considerations

Custom resources expand the attack and failure surface because they can hide sensitive capabilities behind objects that look benign. If authorization tests do not cover those resources, teams may unknowingly leave privilege paths open for escalation, controller abuse, or unintended access to data and infrastructure actions.

Failure mechanism: Test coverage or policy tooling is anchored to native Kubernetes kinds, so dynamically introduced API resources are not evaluated for the same verbs, roles, and edge cases. That creates a gap between intended least privilege and the permissions that are actually enforced.

Impact: An attacker or overprivileged operator can use the missed resource path to reach higher-impact actions, trigger privileged controller behavior, or exploit a policy blind spot that survives normal review.

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 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 Non-Human Identity Top 10	NHI-05 — Overprivileged NHI	Custom resources can widen effective permissions beyond intended RBAC scope.
	NHI-06 — Insecure Cloud Deployment Configurations	Dynamic resources create deployment-specific authorization gaps that tools may miss.
Recommendation — Test live API objects for overbroad access and remove excess permissions. Validate custom-resource permissions against the actual cluster configuration.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Permission testing here is fundamentally about ensuring access stays constrained to needed actions.
	CM-8 — System Component Inventory	Custom resources must be discoverable before they can be tested and governed properly.
Recommendation — Review and enforce least-privilege access across all Kubernetes resource types. Maintain an up-to-date inventory of all API groups and custom resources.
CIS Controls v8	CIS-6 — Access Control Management	Kubernetes RBAC testing is an access-control exercise that must cover dynamic resources.
Recommendation — Test and enforce access rules across native and custom Kubernetes objects.

Practitioner Guidance

What to verify: Treat API discovery as part of the test plan. Confirm that your permission checks include every active API group, every custom resource your platform installs, and every verb that could change state, not just read-only access.

Common mistake: Teams validate roles against a known baseline of core objects and stop there. That is enough to prove a policy file exists, but not enough to prove the policy still holds once an extension adds new authorization targets.

Practitioner takeaway: The right question is not “do we have RBAC tests?”, but “do our tests exercise the full live authorization surface the cluster will actually enforce?”