设备授权怎么做最稳
按最小必要原则把宿主设备节点映射进容器：默认权限是可读可写可创建节点，只需读取时要显式声明只读。动态设备可以用设备规则控制范围，避免把整类设备都放开。
基本信息
| 语法 | --device=/dev/设备[:容器内路径][:r|w|m] |
|---|---|
| 默认权限 | 可读可写可创建节点 |
| 只读声明 | 加 :r 后缀 |
| 动态设备 | 用设备规则限定范围 |
| 风险原则 | 授权范围越大越难审计 |
典型使用场景
- 需要访问串口、USB 等外设的采集类容器
- 调试硬件相关应用时映射单个设备节点
- 视频采集或编码加速类容器
- 避免使用特权模式而只需单个设备时
- 审计现有容器的设备授权范围
映射与核对
映射与核对
docker run --rm --device=/dev/ttyUSB0:/dev/ttyUSB0:r alpine ls -l /dev/ttyUSB0
docker run -d --device-cgroup-rule='c 189:* rmw' --name usb usb/collector:1.0
docker inspect -f '{{json .HostConfig.Devices}}' usb # 核对设备授权授权方式对照
| 授权方式 | 范围 | 适用场景 |
|---|---|---|
| 单个设备节点 | 最小 | 明确只用某一个设备 |
| 只读授权 | 更小 | 仅需读取的场景 |
| 设备规则 | 较大 | 设备会动态出现 |
| 特权模式 | 最大 | 尽量避免，需要专门评审 |
把设备给容器等于把该硬件的控制权交给容器内进程，评估仍以最小集为原则。
不写权限位时默认是可读可写可创建节点，只读设备要显式声明，否则容器内可以写入。
整块存储或内存映射类设备尽量不要给容器，授权范围越大越难审计。
设备会动态出现时用规则限定范围，比逐个映射节点更实用，但要控制规则覆盖的面。
审计时把容器实际获得的设备清单列出来，比只看启动参数更可靠。
很多场景用特权模式只是为了一个设备，改成单设备授权能显著收窄影响面。
设备在容器内的路径可以改写到其他位置，应用配置里写死的路径要跟着调整，否则会表现为设备不存在。