容器安全面试题通常不会只停留在概念层面，而是围绕一条完整的攻击链展开：镜像来源是否可信、容器运行时是否具备足够限制、容器逃逸后能否触达宿主机、集群内部东西向流量是否可控。面试官常从你简历里的 Docker 或 Kubernetes 经验切入，先问基础隔离模型，再逐步加码到具体配置与故障分析。准备这类问题时，建议把每一层防御对应的命令和 YAML 字段都亲手验证一遍，而不是只记住几个名词。
下面按四个高频方向整理面试问题和回答思路，并给出关键配置示例。
一、容器隔离模型：为什么不能说容器等于轻量级虚拟机
面试官经常会让候选人比较容器和虚拟机的安全边界。容器通过 Linux namespace 隔离进程、网络、挂载点等视图，通过 cgroup 限制 CPU 和内存，但它并不虚拟化内核。所有容器共享宿主机的同一个内核，因此一旦容器内的进程利用内核漏洞完成提权，就可能影响宿主机或其他容器。虚拟机则依赖 Hypervisor 提供独立内核，隔离层级更硬，但资源开销也更大。
理解这一点后，回答容器逃逸类问题就会更有条理。例如，如果容器以 root 用户运行，并且没有裁剪 Capabilities，攻击者一旦在容器内获得代码执行能力，就可能尝试利用内核漏洞、挂载宿主机目录或访问 Docker Socket 来逃逸。常见的加固手段包括：以非 root 用户运行、禁用特权模式、去掉不必要的 Capabilities、开启 user namespace 以及限制容器对宿主机路径的访问。下面这条命令展示了如何用普通用户身份启动容器，并移除全部默认 Capabilities，只保留绑定低端口所需的一项。
docker run --rm -d \ --name secure-app \ --user 10001:10001 \ --cap-drop ALL \ --cap-add NET_BIND_SERVICE \ --security-opt no-new-privileges \ --security-opt seccomp=default \ --read-only \ --tmpfs /tmp:rw,noexec,nosuid,size=64m \ -p 8080:8080 \ myapp:latest
需要特别澄清的是，Docker 默认给 root 容器分配的并不是完整 root 权限，而是一组经过裁剪的 Capabilities。即便如此，默认集合仍偏大，足以支撑很多逃逸或横向移动场景。面试时如果能主动提到 CAP_SYS_ADMIN、CAP_NET_RAW 等高风险能力，并说明如何用 --cap-drop ALL 收敛，会比只回答“容器不安全”更有说服力。
二、镜像安全：构建源头如何决定最终攻击面
镜像安全是容器供应链安全的核心。面试中常见的问法是“你如何保证生产镜像安全”，回答应当覆盖构建、扫描、签名和运行时校验四个环节。首先，基础镜像尽量选择 Alpine、Distroless 或经过裁剪的发行版，避免携带不必要的包管理器、编译器和调试工具。多阶段构建可以把编译依赖留在 builder 阶段，最终镜像只拷贝二进制文件和运行时依赖，从而显著减少漏洞数量和攻击面。
其次，镜像构建完成后需要接入漏洞扫描工具，例如 Trivy、Grype 或云平台的镜像扫描服务。这些工具会解析镜像分层并比对 CVE 数据库，输出高危漏洞清单。面试时可以强调扫描不是一次性动作，而应当集成到 CI 流水线，对每一次构建产物进行阻断或告警。对于基础镜像，也可以定期重新构建，确保底层系统包及时修复已知漏洞。
# 多阶段构建：编译与运行分离 FROM golang:1.21 AS builder WORKDIR /src COPY . . RUN CGO_ENABLED=0 go build -o /app . FROM alpine:3.18 RUN apk add --no-cache ca-certificates && rm -rf /var/cache/apk/* RUN addgroup -S appgroup && adduser -S appuser -G appgroup USER appuser COPY --from=builder /app /app ENTRYPOINT ["/app"]
最后，镜像签名和内容信任能降低镜像被篡改或投毒的风险。Docker Content Trust 使用数字签名验证镜像来源和完整性，Kubernetes 中可以通过准入控制器校验镜像签名或只允许来自私有仓库的镜像。面试时如果能区分“扫描漏洞”和“验证来源”是两种不同机制，会显得对供应链安全有整体认识。
三、运行时安全：只读文件系统、非 root 与 Seccomp 如何配合
容器运行时安全的面试题往往从“容器要不要用 root”切入。答案并不是简单的“不要用 root”，而是需要结合业务场景判断。对于大多数无状态应用，应当设置非 root 用户运行，同时开启 no-new-privileges 防止进程通过 setuid 或 Linux capabilities 提权。容器文件系统可以设置为只读，临时写入放到 tmpfs 中，这样即使应用被攻破，攻击者也难以持久化写入启动脚本或替换二进制文件。
除了用户和文件系统，Seccomp 和 AppArmor 是更细粒度的内核安全机制。Docker 默认启用 Seccomp 过滤器，会阻断一部分高风险系统调用；Kubernetes 中可以通过 seccompProfile 设置为 RuntimeDefault，避免使用 Unconfined。AppArmor 或 SELinux 则可以按路径或标签限制文件访问。面试时如果被问到如何防止容器逃逸，至少要提到：非 root、裁剪 Capabilities、只读根文件系统、禁用特权模式、限制系统调用，而不是只记住一个 --privileged 的反面案例。
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
securityContext:
runAsNonRoot: true
runAsUser: 10001
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: myapp:latest
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
还有一个容易被忽略的点是 allowPrivilegeEscalation。它决定容器进程是否可以通过 setuid 或文件能力位获得更多权限。即使容器以非 root 用户启动，如果该字段为 true，某些带有 setuid 位的程序仍可能被利用。因此安全基线通常要求显式设为 false，并与 runAsNonRoot: true 配合。这些字段看似细小，但在面试中能体现出你做过真实加固，而不是纸上谈兵。
四、Kubernetes 安全：RBAC、NetworkPolicy 与 Pod Security 的面试要点
进入 Kubernetes 层面后，面试官的关注点会从单机容器转移到集群控制面和东西向流量。RBAC 是最常问的主题之一。核心原则是最小权限，避免直接给 Pod 挂载 cluster-admin 权限，也尽量避免在默认 ServiceAccount 上绑定过高权限。可以通过 Role 和 RoleBinding 限定命名空间内权限，ClusterRole 只在确实需要集群级资源时使用。回答时最好举例：一个日志采集组件只需要读取 Pod 列表，就不该拥有创建或删除权限。
NetworkPolicy 是另一个高频考点。Kubernetes 默认允许所有 Pod 之间通信，这在多租户或微服务环境中风险很高。面试时可以说明如何先用一条默认拒绝全部流量的策略，再按需放通前端到后端、后端到数据库的路径。展示一个简单的 YAML 片段会让回答更具体。注意 NetworkPolicy 需要 CNI 插件支持，单纯创建策略而网络插件不生效也是常见误区。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: app-network-policy
spec:
podSelector:
matchLabels:
app: secure-app
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 8080
egress:
- to:
- podSelector:
matchLabels:
role: database
ports:
- protocol: TCP
port: 5432
Pod Security 方面，面试官常问怎样强制所有工作负载以非 root 运行或禁用特权容器。早期通过 PodSecurityPolicy，但该资源已在较新版本中弃用，现在更多使用 Pod Security Admission 或第三方准入控制。回答时可以说明集群设置了 restricted 模式后，违规 Pod 会被拒绝创建。此外，Secret 管理也常被问到，避免把数据库密码明文写进环境变量，可以使用挂载卷、外部密钥管理服务或启用静态加密。综合来看，Kubernetes 安全不是单一开关，而是 RBAC、网络策略、准入控制、Secret 管理共同组成的纵深防线。