linux capabilities是内核提供的细粒度权限机制，将root特权拆分为40+个独立能力；docker默认保留约14项，安全实践应从--cap-drop=all起步，按需添加如cap_net_bind_service等必要能力，结合capsh --print验证、strace定位真实依赖，并在k8s中通过securitycontext.capabilities精细化管控。
Linux Capabilities 是 Linux 内核提供的细粒度权限控制机制，它把传统 root 的“全有或全无”特权拆解为 40+ 个独立能力（如 CAP_NET_BIND_SERVICE、CAP_SYS_TIME）。在容器中，合理使用 --cap-drop 和 --cap-add 能显著缩小攻击面，避免以 root 运行却拥有不必要的内核权限。
理解默认行为与最小化起点
Docker 默认启动容器时会保留约 14 个常用 capability（如 CAP_CHOWN、CAP_SETUIDS、CAP_NET_BIND_SERVICE），但移除 CAP_AUDIT_WRITE、CAP_SYS_ADMIN 等高危项。安全实践建议：从 --cap-drop=ALL 开始，再按需逐个添加必要能力，而非默认保留再删减。
- 运行容器时加
--cap-drop=ALL后，普通非 root 进程几乎无法执行任何特权操作 - 若应用需监听 80 端口，仅添加
--cap-add=CAP_NET_BIND_SERVICE，无需开CAP_SYS_ADMIN - 用
capsh --print在容器内验证当前生效的能力集，确认无冗余项
识别真实依赖：从进程行为反推所需能力
不要凭经验猜测，而应观察进程实际系统调用。推荐组合使用 strace + capsh 定位缺失能力：
- 在开发环境用
strace -e trace=capget,setuid,setgid,socket,bind,openat运行程序，关注EPERM错误的上下文 - 若日志出现
Operation not permitted且发生在clock_settime()，说明需要CAP_SYS_TIME - 若容器内
mount失败，先检查是否真需挂载 —— 多数场景可用 bind mount 或 volume 替代，无需CAP_SYS_ADMIN
规避高危 capability 的替代方案
某些 capability 风险极高，应优先考虑替代路径而非直接授予：
-
CAP_SYS_ADMIN：覆盖文件系统、命名空间、设备管理等数十种操作，绝大多数容器无需。用docker run --tmpfs /run --read-only或预置配置文件代替运行时修改 -
CAP_NET_ADMIN：用于配置路由、iptables 等。网络策略交由宿主机或 CNI 插件处理，容器内只收发流量 -
CAP_DAC_OVERRIDE：绕过文件读写权限检查。改为用chown初始化数据卷权限，或以匹配 UID/GID 的用户运行
在 Kubernetes 中落地精细化管控
K8s 通过 securityContext.capabilities 支持相同语义，但需注意字段层级和默认继承逻辑：
- Pod 级设置会作用于所有容器；容器级设置可覆盖 Pod 级，更推荐后者
- 示例配置中显式声明
drop: ["ALL"]和add: ["NET_BIND_SERVICE"]，不依赖注释或文档推测 - 配合
runAsNonRoot: true和readOnlyRootFilesystem: true形成纵深防御
