微服务容器启动时必须禁止 root 权限运行，Dockerfile 中 USER 指令需置于 COPY 后、ENTRYPOINT 前并指定 UID 数字，Kubernetes 需同时设置 securityContext.runAsUser 和 runAsNonRoot: true。
微服务容器启动时禁止 root 权限运行
Go 编译出的二进制文件默认无依赖，容易被直接 exec 运行，但若容器以 root 用户启动，一旦程序存在内存越界或命令注入漏洞，攻击者可直接获得容器内最高权限。Kubernetes 和 Docker 都支持强制降权，关键不是“能不能”，而是“是否在 entrypoint 前就生效”。
- 在
Dockerfile中必须使用USER指令，且放在COPY之后、ENTRYPOINT之前；USER必须指定 UID 数字（如1001），避免依赖镜像中未定义的用户名 - 不要用
gosu或su-exec在 runtime 切换用户——Go 程序本身不 fork，切换无意义，反而增加攻击面 - Kubernetes 中需同时设置
securityContext.runAsUser和runAsNonRoot: true，否则 Pod 可能因镜像USER被忽略而回退到 root
FROM golang:1.22-alpine AS builder WORKDIR /app COPY . . RUN CGO_ENABLED=0 go build -a -ldflags '-extldflags "-static"' -o server . FROM alpine:3.19 RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001 USER 1001:1001 COPY --from=builder /app/server /usr/local/bin/server ENTRYPOINT ["/usr/local/bin/server"]
Go HTTP 服务默认禁用不安全的 header 和重定向
Go 的 net/http 默认不设防：没有 X-Content-Type-Options、允许任意 Host 头、重定向不校验目标域——这些在微服务东西向调用中极易被利用，尤其当服务暴露在 Ingress 后又反向代理到其他 Go 服务时。
- 禁用自动重定向：所有
http.Client实例必须显式设置CheckRedirect，返回http.ErrUseLastResponse或自定义校验逻辑 - 响应头加固：用中间件统一写入
X-Frame-Options: DENY、X-Content-Type-Options: nosniff，注意不要覆盖健康检查端点（如/healthz）所需的轻量响应 - 拒绝非法
Host头：在http.ServeMux前加一层 handler，对r.Host做白名单匹配，不匹配则返回 400；别依赖Request.URL.Host，它可能被重写过
func secureHandler(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
if !validHost(r.Host) {
http.Error(w, "Bad Host", http.StatusBadRequest)
return
}
w.Header().Set("X-Frame-Options", "DENY")
w.Header().Set("X-Content-Type-Options", "nosniff")
next.ServeHTTP(w, r)
})
}
func validHost(h string) bool {
allowed := map[string]bool{"api.example.com": true, "10.244.1.5:8080": true}
return allowed[h]
}
容器镜像构建阶段剥离调试工具与符号表
Go 编译产物虽小，但默认包含 DWARF 符号信息，且多阶段构建若未清理中间层，历史镜像层仍可能残留 /usr/bin/strace、curl、sh 等——攻击者一旦逃逸到容器内，这些就是提权跳板。
- 编译时加
-ldflags="-s -w"：-s去除符号表，-w去除 DWARF 调试信息；二者缺一不可 - 基础镜像必须用
alpine或distroless，禁用debian/ubuntu类含包管理器的镜像；gcr.io/distroless/static-debian12是较新选择，不含 shell - 构建缓存要隔离：CI 中不同服务不能共用同一
build cache目录，防止某服务误引入其他服务的测试依赖（如github.com/go-delve/delve）
Kubernetes 中限制 Go 微服务的资源与能力边界
Go 程序内存增长快、goroutine 泄漏难察觉，若不限制，单个异常服务可能拖垮整个节点。更隐蔽的是 CAP_NET_RAW 这类 capability——Go 的 net.InterfaceAddrs() 不需要它，但某些监控 SDK 会悄悄请求，开启后等于允许容器发原始包。
立即学习“go语言免费学习笔记（深入）”；
-
resources.limits.memory必须设置，且建议比requests高 20%~30%；Go runtime GC 触发阈值与GOMEMLIMIT强相关，不设 limit 会导致 OOMKilled 不可预测 -
securityContext.capabilities.drop至少包含["ALL"]，再按需add（如仅需NET_BIND_SERVICE绑定 80 端口） - 禁用
securityContext.allowPrivilegeEscalation: true，哪怕服务真需要ptrace，也应改用 eBPF 工具在宿主机侧采集，而非容器内提权
最易被忽略的一点：Go 的 http.Server.ReadTimeout 和 WriteTimeout 已被标记为 deprecated，但大量旧代码仍在用；实际应改用 ReadHeaderTimeout + IdleTimeout，否则慢速 HTTP 攻击（如 Slowloris）仍可耗尽连接数——这和容器安全无关，却会让加固形同虚设。
