Description
What would you like to be added?
(This is to start the discussion, I don't have a specific design in mind)
How do we express this access permission/constraint (and similar):
"Only Pods in namespaces N
, M
can access ResourceSlice RS1
, RS2
"
The use case is for fine-grained access to resources at the workload granularity (e.g. by namespace). For example:
"Only the training job has access to GPUs; monitoring pods running on the same node should not be able to access them."
Why is this needed?
Today, as far as I can tell, the permissions could be expressed through Node taints (i.e. only allowed workloads can schedule on the Node with the resource) or via some combination of Gatekeeper + device taints and toleration (only allowed Pods can tolerate T on the device).
This seems like it would be a common use case (Pod/workload-level permissions) that shouldn't need to involve external systems such as Gatekeeper.
Quick thoughts on the personas in the permissions:
- Admin sets up drivers with specific permissions baked into the driver setup.
- Driver exports ResourceSlices that include the permissions.
or maybe three roles:
- Platform/hardware set up drivers
- Driver exports ResourceSlices
- Security authors a policy that associates workloads <=> kinds of slices.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Status