search

squat / generic-device-plugin

A Kubernetes device plugin to schedule generic Linux devices
Apache License 2.0
208 stars 23 forks source link

Namespace-specific Access Control for Low-Level Devices #58

Closed tyb-dev closed 10 months ago

tyb-dev commented 11 months ago

Hi squat!

I am writing to propose a new feature related to access control for low-level devices. This feature aims to enhance the security in managing device access across different namespaces in a Kubernetes environment.

Feature Description

The primary goal is to allow cluster administrators to define which namespaces have access to specific low-level devices. This could be as simple as a list or regex-pattern of namespaces, or perhaps there's a way to use Kubernetes RBAC and your new CRD approach.

Use Case

We're working in a multi-tenant Kubernetes environment and we'd like to make sure only specific pods have access to hardware resources.

Thank you for considering this proposal.

squat commented 11 months ago

@tyb-dev yes! That's a great question! I wonder if this might just be a documentation problem.

There already exists Kubernetes-native way to solve this problem using a ResourceQuota. This seems like a perfect application of that concept as Kubernetes allows restricting access to extended resources, e.g. devices discovered by this plugin. For example, you could limit the number of FUSE devices that could be requested in a namespace by creating a ResourceQuota with a field like requests.squat.ai/fuse: 1. Is there any reason why a ReaourceQuota wouldn't satisfy your needs?

If there's a reason this isn't sufficient, then one solution that comes to mind would be to add an optional namespace allow-list to device specifications; the device plugin will discover devices but will refuse to allocate them to any pod in a namespace outside of the list. An empty list means any namespace can use the devices. This is easy to implement and would be simple to convert to the new CRD world: we could have the concept of Devices and ClusterDevices, much like RBAC Roles and ClusterRoles. A downside of this approach is that it is likely to be confusing for unprivileged users: the API will report that the a node has the requested device and Kubernetes will schedule their pod onto the node, but the pod will not be able to start because the device plugin won't give them the device.

That said, I'd prefer to solve this problem in a Kubernetes-native to promote standard solutions to access control that a cluster administrator might want to configure.

squat commented 10 months ago

Closing for now since I think we have a workable solution using resource quotas. Please re-open if you think we need a different solution!