linux capabilities 需按需授权、动态裁剪，并在 ci 阶段强制固化策略，结合运行时验证、分层防御与白名单机制实现可验证、可阻断、可审计的权限控制。
linux capabilities 是容器权限控制的关键切口，不是简单“开或关”，而是按需授权、动态裁剪。在 devsecops 流水线中落地，核心不是加功能，而是把能力控制变成可验证、可阻断、可审计的流水线环节。
在 CI 阶段强制裁剪能力，从构建源头卡住高危调用
不要等镜像跑起来再检查——能力配置必须固化在构建产物中。推荐在 Dockerfile 构建末尾或 CI 脚本中注入能力策略：
- 使用 --cap-drop=ALL 清空默认能力，再用 --cap-add 显式授予必要项（如
NET_BIND_SERVICE绑定 80/443 端口） - GitLab CI 示例：
docker build --cap-drop=ALL --cap-add=NET_BIND_SERVICE -t $IMAGE_NAME . - 若构建环境不支持直接传参（如 Kaniko），改用 seccomp 默认策略 或在 Kubernetes 层通过
securityContext.capabilities补位，但需确保 CI 阶段已校验 YAML 中该字段存在且非空
运行时策略与扫描联动，让能力配置可验证
光写配置没用，得能自动验证是否生效。建议将能力检查纳入流水线安全门禁：
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 用 Trivy config 扫描 Kubernetes YAML，检测
securityContext.capabilities.drop是否包含ALL，或是否遗漏add必需项 - CI 中执行运行时探针：
docker run --rm $IMAGE_NAME sh -c "cat /proc/1/status | grep CapEff"，比对十六进制 Capability 掩码是否符合预期（例如只保留0000000000000400对应 NET_BIND_SERVICE） - 发现不合规时，直接 exit 1 阻断部署，不依赖人工 review
结合用户命名空间与 capability 分层防御
Capability 单独使用有局限：比如 CAP_SYS_ADMIN 在用户命名空间内仍可能被滥用。必须分层加固：
- Dockerfile 中启用 USER 指令 切换非 root 用户（UID > 1000），避免 capability 提权后直接映射宿主机 root
- Kubernetes PodSecurityPolicy 或 Pod Security Admission 中设置
runAsNonRoot: true和seccompProfile.type: RuntimeDefault，形成策略兜底 - 对必须使用
CAP_SYS_MODULE或CAP_NET_ADMIN的特殊场景（如 eBPF 工具），单独打标签、走审批流、限定仅在测试集群运行
建立能力白名单机制，替代“一刀切”禁用
团队常误以为“drop ALL”就是最安全，结果导致应用启动失败、反复调试。真正可持续的做法是建立组织级能力白名单：
- 梳理各业务组件真实需要的能力（如 Web 服务只需
NET_BIND_SERVICE，日志采集器需SYSCALL和CHOWN） - 将白名单写入 CI 模板或 GitOps 策略引擎（如 OPA/Rego），自动校验
capabilities.add是否在列表内 - 每次新增 capability 需提交安全评审 Issue，并关联 CVE 漏洞分析（例如
CAP_DAC_OVERRIDE可绕过文件权限，需确认无敏感路径挂载）
