应使用 distroless 镜像替代 Alpine 运行 Go 二进制，因其仅含应用及必要依赖，无 shell、包管理器，配合非 root 用户、只读根文件系统和镜像签名验证可实现四重安全闭环。
用 distroless 镜像替代 alpine 运行 Go 二进制
alpine 虽轻，但自带 shell、包管理器和大量系统工具，攻击面明显。Go 应用是静态编译的单二进制文件，根本不需要这些——直接用 gcr.io/distroless/static:nonroot 或 gcr.io/distroless/base:nonroot 更安全。
常见错误是沿用老式 Dockerfile，仍 COPY 到 alpine 并保留 apk 工具链；这会让容器里存在 /bin/sh 和可执行权限的 busybox，一旦被逃逸就可提权或横向移动。
- 构建阶段保持用
golang:1.21-alpine（需要 go toolchain） - 运行阶段必须切换到
distroless基础镜像，且显式指定非 root 用户：USER 65532:65532 - 确保
CMD ["./main"]启动的是纯二进制，不依赖/etc/passwd或动态链接库（编译时加CGO_ENABLED=0）
Deployment 中禁用 privileged 和 cap_add 权限
Kubernetes 默认 Pod 是非特权的，但很多人在调试时随手加了 securityContext.privileged: true 或 cap_add: ["NET_ADMIN"]，上线后忘了删——这等于给容器开了 root shell 的绿色通道。
Go 应用几乎从不需要额外能力：监听端口用 containerPort: 8080 即可，绑定 80 端口可通过 Service + NodePort/Ingress 实现，无需 NET_BIND_SERVICE。
- 检查 Deployment 的
spec.template.spec.containers[].securityContext，确认没出现privileged、cap_add、allowPrivilegeEscalation: true - 强制设置
runAsNonRoot: true和runAsUser: 65532（与 distroless 镜像 UID 对齐） - 若使用
hostNetwork: true或hostPID: true，必须有明确理由并走安全评审
用 readOnlyRootFilesystem + drop capabilities 最小化攻击面
Go 应用运行时只读取配置、写日志到 stdout、偶尔写临时文件（比如 Prometheus metrics scrape 时的临时缓存）。它不需要写根文件系统——启用 readOnlyRootFilesystem: true 能阻断大部分恶意 payload 注入和持久化行为。
配合 drop: ["ALL"] 可进一步剥离所有 Linux capability，只剩进程自身必需的（如 setuid 在非 root 下也无效），这是 distroless + non-root 组合下的关键加固点。
- 在容器
securityContext中添加：readOnlyRootFilesystem: true -
capabilities:下只留必要项（通常为空），并显式drop: ["ALL"] - 若需写临时文件，通过
emptyDirvolume 挂载到/tmp，而非放开整个 rootfs
镜像扫描与签名验证必须嵌入 CI/CD 流程
再干净的 Dockerfile，如果 base 镜像本身含漏洞（比如旧版 distroless 中的 glibc CVE），或者中间层被镜像仓库劫持，安全就形同虚设。Kubernetes 本身不校验镜像完整性。
实际落地时容易忽略两点：一是只扫构建后的镜像，没扫基础镜像；二是没在 imagePullPolicy: Always 前加签名验证，导致拉取到被篡改的镜像。
- CI 阶段用
trivy image --severity CRITICAL扫描最终镜像，并失败构建 - 在集群中部署
cosign+kyverno或opa-gatekeeper，强制校验image: your-registry/go-app@sha256:...的签名 - 避免使用
latest标签；生产 Deployment 必须用 digest（@sha256:...）拉取镜像
真正卡住安全水位线的，往往不是某项配置开关，而是 distroless 镜像 + non-root 用户 + read-only rootfs + 签名验证这四者的组合闭环。少一个，攻击者就可能绕过三层防御直抵最后一环。
