容器必须降权运行、禁挂敏感路径、启用镜像签名、实施默认拒绝网络策略。具体包括：Dockerfile设USER 1001，K8s配runAsNonRoot；禁止挂载/proc、/sys等；开启DOCKER_CONTENT_TRUST；NetworkPolicy显式定义ingress/egress并覆盖全Pod。
容器运行时权限必须降为非 root
绝大多数容器默认以 root 身份启动，一旦镜像或应用存在漏洞，攻击者能直接获得宿主机级权限。这不是理论风险——docker exec -u 0 进去就能验证权限是否真被限制。
实操建议：
- 在
Dockerfile中显式声明USER 1001（非 0 的 UID），并确保该用户对所需目录有读写权限 - Kubernetes 场景下，必须设置
securityContext.runAsNonRoot: true和securityContext.runAsUser: 1001 - 避免用
user: "root"或user: "0"覆盖配置，某些基础镜像（如alpine:latest）默认没创建非 root 用户，得自己adduser - 注意：Java 应用若绑定
80端口，不能靠降权解决——改用8080，别在容器里开setcap 'cap_net_bind_service=+ep' /usr/bin/java
禁止挂载敏感宿主机路径
/proc、/sys、/var/run/docker.sock 这类路径一旦挂进容器，等于把宿主机控制权交出去。常见错误是调试时随手加 -v /var/run/docker.sock:/var/run/docker.sock，结果 CI 容器能拉取并运行任意镜像。
实操建议：
- 检查所有
docker run命令和volumeMounts，删除任何指向/proc、/sys/fs/cgroup、/etc/shadow的挂载 - 确需访问宿主机信息（如获取节点 IP），优先用 downward API 或
hostNetwork: true，而非挂载/proc/sys/net - Kubernetes 中启用
PodSecurityPolicy（旧版）或PodSecurity Admission（1.25+），限制hostPath类型为readOnly且路径白名单化 - 注意：
/dev挂载也要谨慎——/dev/sda可能被误读为块设备，/dev/null除外
镜像必须启用内容信任与签名验证
不验签的镜像等于盲装二进制包。Docker Hub 上大量流行镜像（如 node:18）虽官方维护，但中间传输链路未加密，MITM 攻击可替换层数据。错误现象是：docker pull nginx:alpine 成功，但实际拉下的镜像哈希与官网文档不符。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
实操建议：
- 启用 Docker 内容信任：
export DOCKER_CONTENT_TRUST=1，此后所有pull、push强制校验签名 - 私有 Registry（如 Harbor）必须开启
notary或集成 Cosign，推送前用cosign sign签名，拉取时用cosign verify - CI 流水线中禁止使用
FROM ubuntu:latest，改用带 digest 的固定版本：FROM ubuntu@sha256:abc123... - 注意：
docker build --no-cache不影响镜像签名有效性，但docker load进来的镜像默认无签名，需重新 sign
网络策略必须默认拒绝，按需放行
默认允许所有容器间通信是最大误区。一个被攻破的 redis 容器能直接扫描同 namespace 下的 etcd 端口，只因没设网络隔离。错误日志里常看到 Connection refused 是好事，timeout 才危险——说明连接发出去了但没回包，可能已被防火墙丢弃或目标端口开放。
实操建议：
- Kubernetes 中禁用
default-deny的 NetworkPolicy 无效，必须显式创建一条匹配全部 Pod 的egress: []+ingress: []规则 - 用
calicoctl或kubectl apply -f部署策略时，确认policyTypes包含["Ingress", "Egress"]，否则只生效入向 - 避免用
ipBlock放行整个10.0.0.0/8，应精确到服务 ClusterIP 或 endpoint IP；出向 DNS 必须显式允许port: 53，否则curl google.com会卡住 - 注意：
hostNetwork: true的 Pod 完全绕过 NetworkPolicy，这类 Pod 必须单独加固或隔离到专用节点
真正难的不是配几条规则，而是持续发现隐性依赖——比如某业务突然连不上数据库，查半天发现是新上线的 NetworkPolicy 拦了健康检查探针的源端口范围。自动化策略生成工具容易漏掉这种动态端口，得靠 eBPF 工具（如 Cilium CLI）实时抓包验证。
