Kubernetes安全基础
2026 年，有研究者扫描了几千个暴露在外网的 Kubernetes API 服务器，结果发现其中上千个都能从公网直接访问，而且很多用的是默认或弱认证。大量事例显示，不少集群直接开着 6443 端口、允许匿名访问——相当于把控制面拱手送给了攻击者。这绝不是某种国家级的「高级攻击」，它就是一个「配置疏漏」。
关于 Kubernetes 安全，有个让人不太舒服的真相：这个平台本身并不是「默认不安全」的——恰恰相反，它出厂自带一套分层默认配置；但问题在于，为了让集群「能跑起来」，人们太容易在折腾的过程中把这些默认配置一项项关掉了。我见过的大多数严重 Kubernetes 事故，回溯起来都源于「先跑通了再说、之后再加固」的做法，而不是攻击者真的破解了什么加密算法。
按检查清单的思路理解 K8s 安全
这篇指南采用「检查清单驱动」的方式来讲基础，因为 Kubernetes 安全不是某一个工具能搞定的，而是一整套互相咬合的机制：控制面、工作负载、网络、数据、供应链，每一步都要加固，最后再验证。好消息是：大多数加固动作是免费的配置，而不是企业级授权费用。坏消息是：配置面实在太大，团队很容易漏掉其中一项，于是把「没出事」误当成「很安全」。
加固控制面与 API 服务器
API 服务器是进入你集群的「大门」，也是攻击者最先来撬的地方。这些几乎是没得商量的基本功：把控制面组件跑在严格对公网做了防火墙的主机上、把 API 服务器限制到 TLS 1.2 及以上、并关闭匿名认证。在 EKS、AKS、GKE 这类托管平台上，控制面虽然由云厂商替你管理，但负责锁定「私有网络端点」和 IAM 到角色的映射，仍然是你的责任。
RBAC（基于角色的访问控制）是授权层——它把「谁能跟 API 说话」细化为「谁能做什么」。要为服务账号设置最小权限，别给任何不需要的东西授 `cluster-admin` 或 `*` 通配符权限。一个很常见的泄露路径是：某个权限过大的服务账号被挂进 pod，token 被窃取后用来横向移动。请把每一个服务账号 token 都当作「可能泄露的凭据」来对待，从一开始就按最小权限来设，而不是事后亡羊补牢。
工作负载加固：镜像、特权与 Pod 安全
大多数运行时漏洞，都是因为容器以超出必要的特权运行所致。按优先级列出的工作负载加固检查清单如下：
- 以非 root 用户运行容器：设 `runAsNonRoot: true`，并设 `allowPrivilegeEscalation: false`。
- 用 `drop: ["ALL"]` 丢弃全部 Linux 能力，再只把二进制真正需要的加回来。
- 设 `readOnlyRootFilesystem: true`，让被攻陷的进程无法写入自己的镜像层。
- 使用不可变、固定版本的镜像摘要（digest），而不是 `latest` 这类可变标签，并在部署前扫描镜像里的已知 CVE。
- 采用 Pod 安全标准（PodSecurityStandards，PSA，是 PodSecurityPolicy 的继任者）：在你的命名空间里跑 `restricted`，至少也跑 `baseline`，通过准入控制器生效。
光做镜像扫描并不足够——它能发现基础镜像里的已知 CVE，却抓不住运行时的配置问题。要把扫描和「部署时准入策略」（通过准入控制器，或用 Kyverno、OPA Gatekeeper 这类工具）结合起来，在部署那一刻就拦截有特权的负载，而不是寄希望于开发人员自觉看公告。趁还在学基础阶段，就试着在集群范围统一施加这些控制——这正是你在结构化学习里该打下的底线。想系统打底，可以看看我们的Docker 入门指南。
网络策略：你可能缺失的「东西向防火墙」
很多团队只做了「南北向」的防护（对外网进出做限制），却忽略了「东西向」——集群内部 pod 与 pod 之间、服务与服务之间的流量。默认情况下，Kubernetes 网络里的 pod 之间可以自由通信，而攻击者一旦打进一个 pod，就能利用这种全通网络去横向扩散。
要用 NetworkPolicy 默认拒绝未知流量，再按需放行。具体做法：为每个命名空间定义一套默认拒绝的网络策略，然后只允许业务明确需要的 pod 对 pod、pod 对服务之间的访问。配合上面对外网端点的封锁，这相当于在集群内部又立了一道防火墙。这里顺带提醒：网络加固与容器/DevOps 的工程素养高度相关，若你想把基础打牢，英文站的 Docker 入门指南 和 数据库设计原则 可以一起看。
关键安全层级与建议工具对比表
下面把上面讲到的几大安全层级、它们解决的威胁、以及常用的加固工具汇总成一张表，方便你对照自己的集群逐项打勾。
| 加固层级 | 主要威胁 | 建议做法/工具 | 成本 |
|---|---|---|---|
| 控制面 / API 服务器 | 对外暴露、匿名访问、暴力破解 | 严格防火墙、TLS 1.2+、关闭匿名认证 | 免费（配置） |
| 授权（RBAC） | 权限过大、token 泄露后横向移动 | 最小权限、避免 cluster-admin 与 * | 免费（配置） |
| 工作负载 | 特权容器、镜像 CVE、运行时逃逸 | runAsNonRoot、drop ALL、PSA restricted | 免费（配置）+ 扫描工具 |
| 网络 | 东西向横向扩散 | NetworkPolicy 默认拒绝再放行 | 免费（配置） |
| 数据与密钥 | Secret 泄露、明文存储 | etcd 加密、KMS、外部密钥托管 | 部分云服务按量付费 |
| 供应链 | 恶意镜像、被攻陷依赖 | 锁定镜像源、镜像签名、CI 权限收敛 | 按 CI/仓库服务定价 |
表格里绝大多数「建议做法」都不需要额外采购，属于配置层面的纪律；真正要花钱的主要是镜像扫描、密钥托管、CI 管道这类托管服务。先把握住免费项，再按需补付费项，就能把有限的预算花在刀刃上。
数据安全、密钥与供应链
数据层要加密，别把密钥硬编码在镜像或清单里。Kubernetes 里有个天然的坑：Secrets 对象的 base64 只是「编码」而非「加密」，任何能读到 etcd 或拥有读权限的人都能看到明文。生产环境务必启用 etcd 加密、使用云厂商的 KMS 或外部密钥托管，并给 Secret 打开 RBAC 限制，只让需要的服务读取。
供应链也很关键：锁死镜像源头（只能从受信任的镜像仓库拉取）、校验镜像签名、对 CI/CD 管道做权限收敛。许多攻击者搞不定集群本身，却会通过攻陷第三方依赖或镜像仓库来把你从内部带崩。把供应链当成集群的另一道门来守。
基线配置与持续验证
加固从不该是一锤子买卖。推荐把下面这些低成本、高回报的动作做成常态：定期用 `kube-bench` 之类的工具对照 CIS Kubernetes Benchmark 跑一次基线检查；持续审计集群审计日志，尤其关注异常的 RBAC 变更、陌生镜像的 pod 创建和 API 端点的非预期暴露；把「未加固就上线」的原则做成准入策略，而不是靠口头约定。
记住那句老话：「没出事」不代表「没风险」。许多事故就是在「看起来一直很平静」的假象下发生的——定期验证、持续审计，才是让加固真正生效的最后一块拼图。
常见问题
Kubernetes 默认安全吗？
模块本身出厂带一套分层默认配置，可以说是「相对默认安全」的。真正的风险在于为让它跑起来而关掉这些默认项。关键不是「默不默认」，而是你是否做了系统性加固。
API 服务器常被攻击，最优先加固什么？
优先做这几件事：把控制面对公网严格防火墙、限制到 TLS 1.2+、关闭匿名认证、用最小权限的 RBAC。其次才是工作负载层面的加固。
镜像扫描够用了吗？
不够。它只能发现已知 CVE，抓不住运行时配置问题。必须配合部署时的准入策略（Kyverno/OPA Gatekeeper 等）去拦截有特权的负载，才能形成闭环。
Kubernetes 的 Secret 安全吗？
不「默认安全」。base64 只是编码不是加密。生产环境要启 etcd 加密、用 KMS 或外部密钥托管，并给 Secret 加 RBAC 限制，只让需要的服务可读。
小团队该怎么起步学 K8s 安全？
先把控制面、RBAC、网络策略、密钥这四大块按上面的清单逐项加固，再用 CIS 基线检查工具定期验证。想补容器基础，可以从我们的Docker 入门指南开始，英文站也有 云与 DevOps 课程 可作延伸。
结语：加固是免费配置，带来的回报却很贵
Kubernetes 安全的本质，就是一套环环相扣的检查清单：先把控制面和 API 服务器这扇门锁好，再用最小权限把工作负载压到该有的范围，用网络策略堵住内部东西向的扩散，最后用密钥与供应链防护守住数据和来源，并用持续验证让加固长期有效。好消息是，这些大多只需要严谨的配置，而不是烧钱买「企业授权」。从第一个集群开始就按清单走，你就能把「先跑通、后加固」的隐患扼杀在摇篮里。想真正打牢容器与云的地基，欢迎阅读我们关于Docker 入门和云与 DevOps的完整指南。