Kubernetes 安全基础面试题：RBAC、网络策略、Pod 安全、Secret 管理

本章聚焦 Kubernetes 安全体系四大核心模块：RBAC（基于角色的访问控制）、NetworkPolicy（网络策略）、Pod Security（Pod 安全上下文与安全策略）、Secret 管理。面试中常以场景题考核权限最小化、网络隔离、容器安全合规以及敏感信息保护能力。

安全模块 核心概念 常见考点 面试权重
RBAC Role / ClusterRole / RoleBinding / ClusterRoleBinding 最小权限原则、动词与资源匹配、Subject 类型 ⭐⭐⭐⭐⭐
NetworkPolicy Pod 选择器、Ingress/Egress 规则、CIDR 限制 默认拒绝 vs 白名单、生效维度、实现限制 ⭐⭐⭐⭐
Pod Security SecurityContext、PodSecurityStandard、PSP（弃用） 特权容器、Capabilities、RunAsNonRoot ⭐⭐⭐⭐
Secret 管理 Opaque、ServiceAccount 、加密、etcd 加密 静态加密、RBAC 限制 Secret 访问、注入方式 ⭐⭐⭐⭐⭐
K8s 安全面试回答框架 1. 确认场景与风险 是配置问题还是攻击防御？ 2. 对应安全模块 RBAC / 网络 / Pod / Secret 3. 方案与配置 YAML 示例 / 工具选择 4. 验证 kubectl auth can-i 可能追问方向 原理追问：“为什么？” 对比追问：“与XXX区别？” 故障场景：“如果...会怎样？” 💡 加分点：主动提“最小权限 + 监控 + 审计日志”三位一体

面试问答 1：RBAC 权限设计

面试问题：请设计一个 RBAC 策略，让开发人员只能管理 namespace “dev” 下的 Pod 和 Service，但不能删除 Secret。
考察点 最小权限原则、RBAC 对象关系、动词和资源匹配规则。
回答框架 1. 明确主体（User/Group）和范围（Role vs ClusterRole）；2. 定义 Role 包含 pod/service 的 get/watch/list/create/update，排除 delete；3. 使用 RoleBinding 绑定到 dev 命名空间的 subject；4. 剩余 Secret 访问通过默认 deny 或单独限制。
示例回答 “创建 Role ‘dev-role’，verbs 为 get/list/watch/create/update，resources 为 pods/services；RoleBinding 将用户 app-dev 绑定到该 Role，scope 为 namespace dev。不授予 Secret 的 delete 权限，确保开发者只能操作业务资源。”
可能追问 Q1：如果开发者需要查看 Service Account 隐式关联的 Secret 怎么办？
Q2：如何审计某用户对 Secret 的访问记录？
避坑提醒 ⚠️ 避免在 RoleBinding 中误用 ClusterRoleBinding 导致跨 namespace 越权；注意 verbs 中 ‘deletecollection’ 也需要单独授权。

面试问答 2：NetworkPolicy 实现 Pod 隔离

面试问题：如何配置 NetworkPolicy 使得 frontend 可以访问 backend，但禁止其他 Pod 访问 backend？
考察点 网络策略的入站规则、Pod 选择器、CNI 支持情况。
回答框架 1. 明确默认拒绝所有 Ingress（通过 policyTypes）；2. 编写 NetworkPolicy 选中 backend Pod，在 ingress 中定义 from 选择器匹配 frontend Pod 或对应标签；3. 可补充端口限制增强安全。
示例回答 “为 backend 创建 NetworkPolicy：spec.podSelector.matchLabels.app=backend，ingress 规则 from: - podSelector.matchLabels.app=frontend，并指定 ports: 8080。同时 policyTypes: [Ingress] 实现默认拒绝。”
可能追问 Q1：如果 CNI 不支持 NetworkPolicy（如 Flannel）怎么办？
Q2：如何实现跨 namespace 的访问控制？
避坑提醒 ⚠️ 注意 NetworkPolicy 只作用于 Pod，不控制 Service IP；需确认集群已安装支持 NetworkPolicy 的 CNI 插件（如 Calico、Cilium）。

面试问答 3：Pod Security + Secret 管理

面试问题：如何强制运行容器时禁止特权模式，并且保证 Secret 在 etcd 中加密存储？
考察点 PodSecurityStandard 或 OPA，etcd 加密配置，Secret 的静态加密。
回答框架 1. 启用 PodSecurity Admission（v1.23+）并配置 baseline/restricted 策略；2. 在 PodSecurityContext 设置 privileged: false, runAsNonRoot: true；3. 配置 EncryptionConfiguration 对 Secret 使用 AES-GCM 加密，并重启 kube-apiserver。
示例回答 “通过 PodSecurityStandard 的 restricted 策略自动拒绝特权容器，并设置 runAsNonRoot=321。Secret 加密使用 kubectl create encryptionconfig 写入--encryption-provider-config，将 resources:[secrets] 加密，确保 etcd 中为密文。”
可能追问 Q1：加密密钥如何轮换？
Q2：Pod 中引用 Secret 的方式有哪些安全隐患？
避坑提醒 ⚠️ Secret 加密只保护静态数据，若 Pod 环境变量注入 Secret 仍存在泄漏风险；建议使用 SecretStore CSI 或 External Secrets Operator。

项目案例：金融微服务集群安全加固

项目名称 银行核心交易系统 K8s 安全审计与加固
业务背景 满足 PCI-DSS 合规要求，对存量 200+ 微服务进行最小权限改造、网络微隔离和 Secret 加密。
规模指标 集群节点 50 个，命名空间 30+，Pods 约 1200，RBAC 角色 80 个，NetworkPolicy 160 条。
技术栈 Kubernetes v1.24, Calico CNI + NetworkPolicy, PodSecurityAdmission, External Secrets Operator, etcd 加密 (AES-GCM)
核心难点 1. 改造存量镜像中 privileged 字段；2. 验证 NetworkPolicy 不影响现有服务互访；3. 密钥轮换零停机。
面试高频追问 Q1：如何在不重启 Pod 的情况下更新加密密钥？Q2：网络策略误封导致现网故障如何快速回滚？
可迁移回答话术 “我们采用渐进式灰度策略：先在 test 命名空间验证 NetworkPolicy 规则，通过 Prometheus 监控连通性指标；RBAC 变更前使用 kube-review 工具预检影响范围；Secret 加密主密钥通过 KMS 自动轮换，利用 encryption-config 的 write-key 机制实现热更新。”
💡 面试亮点建议：回答时主动提及 “默认拒绝 + 白名单” 和 “防御纵深” 思路，展示安全体系设计能力。
← 上一章 📖 返回目录 下一章 →