Skip to content

Commit 8df4df1

Browse files
committed
update with tim suggestions
1 parent f529b85 commit 8df4df1

5 files changed

Lines changed: 250 additions & 55 deletions

File tree

content/en/docs/concepts/scheduling-eviction/dynamic-resource-allocation.md

Lines changed: 10 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -383,7 +383,10 @@ DRA drivers can report driver-specific
383383
data for each allocated device in the `status.devices` field of a ResourceClaim.
384384
For example, the driver might list the IP addresses that are assigned to a
385385
network interface device. Updating this field requires specific synthetic RBAC permissions,
386-
see [Granular status authorization](#granular-status-authorization) for details.
386+
see
387+
[Hardening Guide - Dynamic Resource Allocation](/docs/concepts/security/hardening-guide/dynamic-resource-allocation/)
388+
and
389+
[Harden Dynamic Resource Allocation in Your Cluster](/docs/tasks/administer-cluster/hardening-dra/).
387390

388391
The accuracy of the information that a driver adds to a ResourceClaim
389392
`status.devices` field depends on the driver. Evaluate drivers to decide whether
@@ -507,61 +510,14 @@ in the kube-apiserver, kube-scheduler, and kubelet.
507510
{{< feature-state feature_gate_name="DRAResourceClaimGranularStatusAuthorization" >}}
508511

509512
Starting in Kubernetes v1.36, DRA enforces fine-grained authorization checks for updates
510-
to a `ResourceClaim`'s status. In addition to granting `update` permissions on the
511-
`resourceclaims/status` subresource, cluster administrators must grant permissions on
512-
specific "synthetic" subresources based on the exact fields a component needs to modify.
513-
This enforces the principle of least privilege between the scheduler, custom controllers,
514-
and DRA drivers.
515-
516-
The authorization checks are divided into two synthetic subresources:
517-
518-
- **`resourceclaims/binding`**: Required to modify `status.allocation` or `status.reservedFor`.
519-
his permission is typically granted to the Kubernetes scheduler and custom allocation controllers.
520-
It requires standard `update` or `patch` verbs.
521-
522-
- **`resourceclaims/driver`**: Required to modify `status.devices`. This check is performed per-driver
523-
and uses custom node-aware verb prefixes to prevent node-local drivers from tampering with devices on
524-
other nodes.
513+
to `ResourceClaim` status by using synthetic subresources and node-aware verbs.
525514

526-
- **`associated-node:<verb>`** (e.g., `associated-node:update`): Required for node-local drivers.
527-
The API server automatically verifies that the ServiceAccount making the request is securely
528-
associated with the node where the claim is allocated.
529-
- **`arbitrary-node:<verb>`** (e.g., `arbitrary-node:update`): Required for control-plane drivers
530-
or network controllers that manage device statuses across multiple nodes.
515+
For security hardening guidance, including RBAC examples for scheduler and DRA
516+
drivers, see
517+
[Hardening Guide - Dynamic Resource Allocation](/docs/concepts/security/hardening-guide/dynamic-resource-allocation/).
531518

532-
**Example RBAC for a Node-Local Driver:**
533-
534-
```yaml
535-
apiVersion: rbac.authorization.k8s.io/v1
536-
kind: ClusterRole
537-
metadata:
538-
name: example-dra-node-driver
539-
rules:
540-
- apiGroups: ["resource.k8s.io"]
541-
resources: ["resourceclaims/status"]
542-
verbs: ["get", "patch", "update"]
543-
- apiGroups: ["resource.k8s.io"]
544-
resources: ["resourceclaims/driver"]
545-
verbs: ["associated-node:update", "associated-node:patch"]
546-
resourceNames: ["dra.example.com"] # Limit to a specific driver
547-
```
548-
549-
**Example RBAC for a multi-node status controller:**
550-
551-
```yaml
552-
apiVersion: rbac.authorization.k8s.io/v1
553-
kind: ClusterRole
554-
metadata:
555-
name: example-dra-status-controller
556-
rules:
557-
- apiGroups: ["resource.k8s.io"]
558-
resources: ["resourceclaims/status"]
559-
verbs: ["get", "patch", "update"]
560-
- apiGroups: ["resource.k8s.io"]
561-
resources: ["resourceclaims/driver"]
562-
verbs: ["arbitrary-node:update", "arbitrary-node:patch"]
563-
resourceNames: ["dra.example.com"] # Limit to a specific driver
564-
```
519+
For a step-by-step cluster administrator procedure, see
520+
[Harden Dynamic Resource Allocation in Your Cluster](/docs/tasks/administer-cluster/hardening-dra/).
565521

566522
## DRA alpha features {#alpha-features}
567523

Lines changed: 116 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
---
2+
title: "Hardening Guide - Dynamic Resource Allocation"
3+
description: >
4+
Information about hardening Dynamic Resource Allocation (DRA) authorization and access patterns.
5+
content_type: concept
6+
weight: 90
7+
---
8+
9+
<!-- overview -->
10+
11+
Dynamic Resource Allocation (DRA) adds powerful scheduling and device management
12+
capabilities. Because DRA components update `ResourceClaim` status, cluster
13+
administrators should configure authorization for those updates with explicit,
14+
least-privilege RBAC.
15+
16+
{{< feature-state feature_gate_name="DRAResourceClaimGranularStatusAuthorization" >}}
17+
18+
Starting in Kubernetes v1.36, DRA status updates use synthetic subresources and,
19+
in some cases, specialized node-aware verbs.
20+
21+
<!-- body -->
22+
23+
## Harden DRA status update permissions
24+
25+
For DRA status updates,In addition to granting `update` permissions on the
26+
`resourceclaims/status` subresource, cluster administrators must grant permissions on
27+
specific "synthetic" subresources based on the exact fields a component needs to modify.
28+
This enforces the principle of least privilege between the scheduler, custom controllers,
29+
and DRA drivers.
30+
31+
The DRA authorization checks are divided into two synthetic subresources:
32+
33+
- **`resourceclaims/binding`**
34+
- Required to modify `status.allocation` and `status.reservedFor`.
35+
- Typically granted to the kube-scheduler and custom allocation controllers.
36+
- Uses standard `update` and `patch` verbs.
37+
- **`resourceclaims/driver`**
38+
- Required to modify `status.devices`.
39+
- This check is performed per-driver to drivers from tampering with devices on different
40+
nodes and/or from other drivers.
41+
- Uses node-aware verbs for stricter scope.
42+
43+
## Node-aware DRA verbs
44+
45+
When authorizing updates to `resourceclaims/driver`, use the appropriate
46+
specialized verb prefix:
47+
48+
- **`associated-node:<verb>`** (for example, `associated-node:update`)
49+
- For node-local drivers.
50+
- The API server verifies node association for the requesting driver.
51+
- **`arbitrary-node:<verb>`** (for example, `arbitrary-node:patch`)
52+
- For control-plane or multi-node controllers that may update claims from
53+
any node.
54+
55+
## Example RBAC patterns
56+
57+
### Scheduler and allocation controller permissions
58+
59+
```yaml
60+
apiVersion: rbac.authorization.k8s.io/v1
61+
kind: ClusterRole
62+
metadata:
63+
name: dra-binding-updater
64+
rules:
65+
- apiGroups: ["resource.k8s.io"]
66+
resources: ["resourceclaims/status"]
67+
verbs: ["get", "patch", "update"]
68+
- apiGroups: ["resource.k8s.io"]
69+
resources: ["resourceclaims/binding"]
70+
verbs: ["patch", "update"]
71+
```
72+
73+
### Node-local DRA driver permissions
74+
75+
```yaml
76+
apiVersion: rbac.authorization.k8s.io/v1
77+
kind: ClusterRole
78+
metadata:
79+
name: dra-node-driver-status-updater
80+
rules:
81+
- apiGroups: ["resource.k8s.io"]
82+
resources: ["resourceclaims/status"]
83+
verbs: ["get", "patch", "update"]
84+
- apiGroups: ["resource.k8s.io"]
85+
resources: ["resourceclaims/driver"]
86+
verbs: ["associated-node:patch", "associated-node:update"]
87+
resourceNames: ["dra.example.com"]
88+
```
89+
90+
### Multi-node status controller permissions
91+
92+
```yaml
93+
apiVersion: rbac.authorization.k8s.io/v1
94+
kind: ClusterRole
95+
metadata:
96+
name: dra-multinode-status-updater
97+
rules:
98+
- apiGroups: ["resource.k8s.io"]
99+
resources: ["resourceclaims/status"]
100+
verbs: ["get", "patch", "update"]
101+
- apiGroups: ["resource.k8s.io"]
102+
resources: ["resourceclaims/driver"]
103+
verbs: ["arbitrary-node:patch", "arbitrary-node:update"]
104+
resourceNames: ["dra.example.com"]
105+
```
106+
107+
## Related cluster administrator task
108+
109+
To apply these patterns in a running cluster, see
110+
[Harden Dynamic Resource Allocation in Your Cluster](/docs/tasks/administer-cluster/hardening-dra/).
111+
112+
## {{% heading "whatsnext" %}}
113+
114+
- [Authorization](/docs/reference/access-authn-authz/authorization/)
115+
- [Set Up DRA in a Cluster](/docs/tasks/configure-pod-container/assign-resources/set-up-dra-cluster/)
116+
- [Dynamic Resource Allocation](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)

content/en/docs/reference/access-authn-authz/authorization.md

Lines changed: 4 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -64,7 +64,7 @@ Kubernetes reviews only the following API request attributes:
6464
* **API request verb** - API verbs like `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, and `deletecollection` are used for resource requests. To determine the request verb for a resource API endpoint, see [request verbs and authorization](/docs/reference/access-authn-authz/authorization/#determine-the-request-verb).
6565
* **HTTP request verb** - Lowercased HTTP methods like `get`, `post`, `put`, and `delete` are used for non-resource requests.
6666
* **Resource** - The ID or name of the resource that is being accessed (for resource requests only) -- For resource requests using `get`, `update`, `patch`, and `delete` verbs, you must provide the resource name.
67-
* **Subresource** - The subresource that is being accessed (for resource requests only).
67+
* **Subresource** - The subresource that is being accessed (for resource requests only). This can be a standard subresource (for example, `status` or `scale`) or a synthetic subresource used for fine-grained authorization.
6868
* **Namespace** - The namespace of the object that is being accessed (for namespaced resource requests only).
6969
* **API group** - The {{< glossary_tooltip text="API Group" term_id="api-group" >}} being accessed (for resource requests only). An empty string designates the _core_ [API group](/docs/reference/using-api/#api-groups).
7070

@@ -104,6 +104,9 @@ Kubernetes sometimes checks authorization for additional permissions using speci
104104
* **approve** verb for CertificateSigningRequests, and **update** for revisions to existing approvals
105105
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
106106
* **bind** and **escalate** verbs on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
107+
* [Dynamic Resource Allocation (DRA)](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/)
108+
* Synthetic subresources such as `resourceclaims/binding` and `resourceclaims/driver` in the `resource.k8s.io` API group.
109+
* Node-aware verbs such as `associated-node:update`, `associated-node:patch`, `arbitrary-node:update`, and `arbitrary-node:patch` for DRA driver `resourceclaims/status` updates.
107110

108111
## Authorization context
109112

Lines changed: 112 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,112 @@
1+
---
2+
title: Harden Dynamic Resource Allocation in Your Cluster
3+
content_type: task
4+
weight: 330
5+
---
6+
7+
<!-- overview -->
8+
9+
This page shows cluster administrators how to harden authorization for
10+
Dynamic Resource Allocation (DRA), with a focus on least-privilege access for
11+
`ResourceClaim` status updates.
12+
13+
<!-- prerequisites -->
14+
15+
## {{% heading "prerequisites" %}}
16+
17+
- {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
18+
- Dynamic Resource Allocation is configured in your cluster.
19+
- You can edit RBAC resources and restart or roll out DRA components.
20+
21+
<!-- steps -->
22+
23+
## Identify DRA components that write status
24+
25+
Document which identities (usually ServiceAccounts) update ResourceClaim
26+
status in your cluster. Typical writers are:
27+
28+
- kube-scheduler or a custom allocation controller
29+
- node-local DRA drivers
30+
- multi-node DRA status controllers
31+
32+
## Grant least-privilege permissions for synthetic subresources
33+
34+
Starting in Kubernetes v1.36, DRA status updates require synthetic subresource
35+
permissions in addition to `resourceclaims/status`.
36+
37+
### Grant scheduler and allocation-controller permissions
38+
39+
Apply a role that allows binding-related updates:
40+
41+
```yaml
42+
apiVersion: rbac.authorization.k8s.io/v1
43+
kind: ClusterRole
44+
metadata:
45+
name: dra-binding-updater
46+
rules:
47+
- apiGroups: ["resource.k8s.io"]
48+
resources: ["resourceclaims/status"]
49+
verbs: ["get", "patch", "update"]
50+
- apiGroups: ["resource.k8s.io"]
51+
resources: ["resourceclaims/binding"]
52+
verbs: ["patch", "update"]
53+
```
54+
55+
### Grant node-local driver permissions
56+
57+
Use node-aware verbs for node-local drivers:
58+
59+
```yaml
60+
apiVersion: rbac.authorization.k8s.io/v1
61+
kind: ClusterRole
62+
metadata:
63+
name: dra-node-driver-status-updater
64+
rules:
65+
- apiGroups: ["resource.k8s.io"]
66+
resources: ["resourceclaims/status"]
67+
verbs: ["get", "patch", "update"]
68+
- apiGroups: ["resource.k8s.io"]
69+
resources: ["resourceclaims/driver"]
70+
verbs: ["associated-node:patch", "associated-node:update"]
71+
resourceNames: ["dra.example.com"]
72+
```
73+
74+
### Grant multi-node controller permissions only when needed
75+
76+
Use `arbitrary-node:*` only for components that must update from any node:
77+
78+
```yaml
79+
apiVersion: rbac.authorization.k8s.io/v1
80+
kind: ClusterRole
81+
metadata:
82+
name: dra-multinode-status-updater
83+
rules:
84+
- apiGroups: ["resource.k8s.io"]
85+
resources: ["resourceclaims/status"]
86+
verbs: ["get", "patch", "update"]
87+
- apiGroups: ["resource.k8s.io"]
88+
resources: ["resourceclaims/driver"]
89+
verbs: ["arbitrary-node:patch", "arbitrary-node:update"]
90+
resourceNames: ["dra.example.com"]
91+
```
92+
93+
## Bind roles to explicit identities
94+
95+
Create `ClusterRoleBinding` objects for each component identity, and avoid
96+
sharing a broad role across unrelated DRA components.
97+
98+
Restrict `resourceclaims/driver` rules with `resourceNames` where possible so
99+
an identity can only write status for the specific DRA driver it operates.
100+
101+
## Validate and monitor
102+
103+
1. Verify each identity has only the required verbs and subresources.
104+
1. Confirm DRA status updates work after rollout.
105+
1. Watch API server audit events for denied `resourceclaims/binding` and
106+
`resourceclaims/driver` requests.
107+
108+
## {{% heading "whatsnext" %}}
109+
110+
- [Hardening Guide - Dynamic Resource Allocation](/docs/concepts/security/hardening-guide/dynamic-resource-allocation/)
111+
- [Securing a Cluster](/docs/tasks/administer-cluster/securing-a-cluster/)
112+
- [Authorization](/docs/reference/access-authn-authz/authorization/)

content/en/docs/tasks/administer-cluster/securing-a-cluster.md

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -70,6 +70,14 @@ to prevent accidental escalation. You can make roles specific to your use case i
7070

7171
Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information.
7272

73+
If your cluster uses [Dynamic Resource Allocation (DRA)](/docs/concepts/scheduling-eviction/dynamic-resource-allocation/),
74+
review DRA synthetic subresource authorization (`resourceclaims/binding` and
75+
`resourceclaims/driver`) and grant only the minimum required verbs to each
76+
component. For details, see
77+
[Hardening Guide - Dynamic Resource Allocation](/docs/concepts/security/hardening-guide/dynamic-resource-allocation/)
78+
and
79+
[Harden Dynamic Resource Allocation in Your Cluster](/docs/tasks/administer-cluster/hardening-dra/).
80+
7381
## Controlling access to the Kubelet
7482

7583
Kubelets expose HTTPS endpoints which grant powerful control over the node and containers.

0 commit comments

Comments
 (0)