1. 云原生安全面试全景

云原生安全工程师并不是传统安全工程师加几个Kubernetes命令的简单叠加。它要求你在容器、编排、微服务、CI/CD和基础设施即代码（IaC）构成的动态环境中，重新理解“资产、边界、身份、漏洞、运行时”这些安全基本概念。面试官考察的，也正是你是否完成了这种认知迁移。

一、岗位职责：从“守边界”到“守整条交付链”

从招聘市场看，云原生安全工程师的职责通常落在四条主线上。第一条是基础设施与集群安全：负责Kubernetes集群的基线加固、RBAC权限治理、网络策略（NetworkPolicy）、准入控制（Admission Controller）与密钥管理。第二条是供应链与镜像安全：把安全卡点嵌入CI/CD，做镜像扫描、SBOM生成、签名与验证。第三条是运行时安全：通过Falco、eBPF或审计日志检测容器逃逸、异常进程、横向移动。第四条是安全左移与平台化：把策略写成代码（Policy as Code），用OPA/Gatekeeper、Kyverno等工具让安全能力成为平台的一部分，而不是流程末尾的审批环节。

面试中，面试官往往不会直接问“你负责什么”，而是给一个场景，例如：“生产集群里一个Pod被挖矿了，你怎么定位和处置？”这道题同时考察你的运行时检测能力、Kubernetes排查熟练度和应急响应思路。回答时如果只讲“隔离Pod、删掉它”，会显得单薄；能说出先看kubectl get events、再查审计日志中该ServiceAccount的异常API调用、结合Falco告警确认进程树、最后回溯镜像来源与CI流水线，才是完整的闭环。

二、能力模型：三层结构

把云原生安全工程师的能力拆开，可以归纳为三层。底层是云原生基础：Linux命名空间与cgroups、容器运行时（containerd、CRI-O）、Kubernetes核心对象（Pod、Deployment、ServiceAccount、RBAC、NetworkPolicy）、网络与存储模型。这一层不牢，后面全是空中楼阁。中层是安全专业能力：身份与访问管理、漏洞与配置风险、供应链安全、运行时检测、日志与取证。上层是工程与沟通能力：把安全策略写成可维护的代码、用平台化方式降低业务接入成本、在安全与研发效率之间做权衡。

一个常见的误区是只堆工具名词。面试官问“你怎么做镜像安全”，如果你回答“用Trivy扫描”，这只是一个动作。更完整的回答应包含：在CI的哪个阶段扫、扫描结果如何阻断流水线（例如Critical漏洞直接失败）、基础镜像如何统一维护、扫描策略如何避免误报导致研发抵触。工具是手段，策略和落地方式才是能力。

三、面试流程与常见考察维度

典型流程为：简历筛选 → 技术初面 → 技术深面/场景面 → 交叉面或主管面 → HR面。技术面通常覆盖以下维度：

其中，场景题是区分度最高的部分。它不考记忆，考的是你在信息不完整时如何拆解问题。例如：“研发说他们的Pod起不来，怀疑是NetworkPolicy导致的，你怎么验证？”合理的做法是：先确认Pod的标签与NetworkPolicy的selector是否匹配，再用kubectl describe networkpolicy查看规则，接着在目标Pod内用nc -zv或curl测试到目标服务的连通性，同时检查DNS解析是否被策略阻断。每一步都有明确的观察点，而不是凭感觉改配置。

四、学习地图：如何用这本题库准备面试

本课程后续章节会按“基础 → 供应链 → 运行时 → 平台化 → 综合场景”推进。建议你按以下方式使用：第一遍通读，标记出自己无法用一句话解释清楚的概念；第二遍针对薄弱章节，把每道题的答案改写成自己的项目语言，例如把“RBAC最小权限”替换成你实际治理过的某个ServiceAccount；第三遍做场景题，强迫自己在纸上写出排查步骤和判断依据。

下面给出一份可直接使用的面试准备自检表，按周填写，帮助你把“看过”变成“能讲清楚”。

以“禁止特权容器”为例，一个可执行的Kyverno策略片段如下，面试中如果能写出并解释validationFailureAction的作用，会明显加分：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-privileged
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: "false"

验证时，创建一个privileged: true的Pod，观察是否被拒绝；再创建一个普通Pod，确认可以正常创建。这个“拒绝+放行”的双向验证，就是面试官想听到的判断依据。