安全威胁
在Kubernetes系统的规划、部署与运维过程中，安全性始终是核心考量之一。相较于事后应对安全事件，主动进行风险识别和预防显得尤为重要。为此，引入威胁建模（Threat Modeling）的理念，可帮助我们系统性地评估并缓解潜在风险。
威胁建模是一种结构化的方法论，通过分析系统的结构与运行环境，识别、分类可能的威胁来源和攻击向量，进而制定相应的防护措施。在安全领域，STRIDE模型被广泛采用，它将常见的安全威胁归纳为六大类。 接下来，我们以STRIDE框架为引导，梳理其在Kubernetes环境中的具体表现及防护建议，为集群安全提供切实可行的指导意见。
身份伪造 (Spoofing)
身份伪造，顾名思义，就是冒充他人或他物。这就像一个间谍伪装成信使，试图骗过城门守卫，窃取机密情报。
在Kubernetes集群中，各种组件（如API Server、Kubelet等）和应用（Pods）之间需要频繁通信。如果一个恶意程序成功伪装成一个合法的组件，它就可能骗取系统的信任，执行未经授权的操作，其后果不堪设想。
为了防止这种情况，Kubernetes采用了一种叫做“双向TLS认证”（mTLS）的机制。你可以把它想象成一个秘密的“对口令”系统。当两个组件需要通信时，它们不仅要验证对方的身份，还要亮出自己的身份证明。只有双方都确认了彼此是“自己人”，通信才会建立。这种机制大大增加了伪装的难度。
在Pod的层面，我们同样需要警惕身份伪造。默认情况下，每个Pod都会自动挂载一个服务账户令牌（ServiceAccount Token），这相当于给了Pod一个在集群内部活动的“身份证”。但大多数应用其实并不需要直接与API Server通信。因此，一个好的实践是，对于不需要访问API Server的Pod，明确设置 automountServiceAccountToken: false，从而收回这张“身份证”，遵循最小权限原则。
数据篡改 (Tampering)
数据篡改是指恶意修改传输或存储中的信息。想象一下，你寄出的一封重要信件，在途中被人拆开，修改了内容，然后再重新封好。收信人可能完全不会察觉，但错误的信息已经造成了危害。
在Kubernetes中，很多关键信息都可能成为篡改的目标，比如：
- etcd中存储的集群状态
- 各个组件的配置文件
- 容器镜像
防止数据篡改的策略可以分为两方面：动态和静态。
对于动态传输中的数据，我们之前提到的TLS加密通信就能发挥作用。它不仅加密数据，还包含了完整性校验，能确保数据在传输过程中没有被“动手脚”。
对于静态存储的数据，比如配置文件和容器镜像，我们可以采取类似“防伪封条”的措施。比如，对文件进行哈希校验（Checksums），确保我们下载和使用的文件是原版。此外，将容器的文件系统设置为“只读”（readOnlyRootFilesystem: true）也是一个非常有效的手段。这就像把一份重要文件放进一个只能看不能改的玻璃柜里，从根本上杜绝了篡改的可能。
行为抵赖 (Repudiation)
“这事不是我干的！”——在数字世界里，如何防止这种“耍赖”行为，就是“防抵赖”要解决的问题。我们需要有确凿的证据，能够证明某个操作确实是某人或某个组件在某个时间点执行的。
这就像一座大楼里无处不在的监控摄像头和门禁刷卡记录。一旦发生安全事件，我们可以通过回放录像和查询记录，准确地追溯到事件的来龙去脉。
在Kubernetes中，这个“监控系统”就是 审计日志（Auditing）。API Server是整个集群的中枢，几乎所有的操作都要经过它。通过开启并妥善保管API Server的审计日志，我们可以记录下每一次API调用的详细信息：谁（user）、在何时（timestamp）、从哪里（sourceIPs）、做了什么（verb）、操作了哪个对象（objectRef）。
仅仅记录日志是不够的，保护日志本身的安全至关重要。如果你的“监控录像”可以被轻易删除或修改，那么所有的记录都将失去意义。因此，通常需要将审计日志发送到一个独立的、高安全性的中央日志存储系统进行集中管理和分析。
信息泄露 (Information Disclosure)
信息泄露是指敏感数据被未经授权的个体获取。这就像你不小心把一把装有所有房间钥匙的万能钥匙弄丢了，后果将是灾难性的。
在Kubernetes中，最敏感的信息莫过于 Secrets 对象，它通常用来存储密码、API密钥、证书等。这些信息都以加密的形式存储在etcd中。然而，这里有一个关键问题：加密数据需要密钥，那解密的密钥又存放在哪里呢？
默认情况下，用于加密Secrets的密钥（DEK）也存放在etcd所在的节点上。这意味着，如果攻击者攻陷了etcd节点，就可能同时拿到“锁”和“钥匙”，从而绕过加密。
一个更安全的做法是，采用“保险箱套保险箱”的策略。我们可以使用一个外部的密钥管理服务（KMS），比如云服务商提供的KMS或者硬件安全模块（HSM）。 在这种模式下，Kubernetes只在需要时向KMS请求一把“临时钥匙”（KEK）来解密本地的DEK，而真正的“万能钥匙”始终保存在外部高度安全的环境中。这极大地降低了核心密钥泄露的风险。
拒绝服务 (Denial of Service)
拒绝服务（DoS）攻击的目的不是窃取信息，而是让你的服务无法正常运行。这就像一群人故意堵在一家商店的门口，让真正的顾客无法进入，导致商店无法营业。
在Kubernetes集群中，DoS攻击的目标可能是：
- API Server：作为集群的大脑，如果它被海量请求淹没，整个集群的管理和调度都将陷入瘫痪。
- 工作节点：某个节点上的资源（CPU、内存）被恶意程序耗尽，可能导致该节点上所有的Pod都无法正常工作。
- 应用程序：应用本身也可能成为攻击目标。
防范DoS攻击的核心思想是“隔离”和“限制”。
- 高可用性（HA）：不要把所有鸡蛋放在一个篮子里。通过在多个节点、甚至多个可用区部署控制平面组件（如API Server），可以避免单点故障。
- 资源配额（Resource Quotas）：为每个命名空间（Namespace）设置资源使用的上限，比如可以创建多少个Pod，能使用多少CPU和内存。这就像给每个租户分配了固定的水量和电量，防止某个租户的滥用影响到其他人。
- 网络策略（Network Policies）：定义Pod之间可以如何通信。默认情况下，集群内的所有Pod可以自由通信，但通过网络策略，我们可以建立“防火墙”，只允许必要的、合法的网络连接。
权限提升 (Elevation of Privilege)
权限提升是指攻击者从一个低权限账户，通过某种手段获得了更高的权限。这就像一个普通员工捡到了CEO的门禁卡，从而可以进入公司的所有保密房间。这是最危险的攻击类型之一。
在容器化的世界里，一个常见的风险点就是以 root 用户身份运行容器内的进程。root 用户在Linux系统中拥有至高无上的权力。如果一个以 root 身份运行的容器被攻破，攻击者很可能利用这个立足点，进一步“逃逸”到宿主机，从而控制整个节点。
为了防止权限提升，Kubernetes提供了多层防御机制：
- 以非root用户运行：在Pod的
securityContext中，强制指定容器内的进程以一个非root用户（如runAsUser: 1000）来运行。这是最基本也是最重要的一条原则。 - 最小化权能（Capabilities）：Linux的
root权限实际上是由一系列更小的“权能”（Capabilities）组合而成的。比如，NET_ADMIN权能允许配置网络。我们可以遵循最小权限原则，只授予容器运行所必需的最小权能集合，而不是给予完整的root权限。 - 禁止权限提升：在
securityContext中设置allowPrivilegeEscalation: false，可以禁止子进程获取比其父进程更高的权限，从而堵住一条常见的提权路径。
使用Pod安全策略（PSP）集中管理
我们前面讨论了许多安全设置，比如runAsUser、readOnlyRootFilesystem等。如果每次部署应用都需要开发者手动在YAML文件中配置这些，不仅繁琐，而且容易出错。
为了解决这个问题，Kubernetes提供了 Pod安全策略（Pod Security Policy, PSP）。你可以把它想象成一个集群级别的“安全合规模板”。管理员可以预先定义好一套或多套安全策略，比如“严格模式”、“宽松模式”等。然后，将这些策略应用到不同的命名空间或服务账户上。
当有新的Pod创建请求时，准入控制器（Admission Controller）会自动检查这个Pod是否符合所应用的安全策略。如果不符合，请求将被拒绝。通过这种方式，企业可以强制推行统一的安全基线，而无需依赖每个开发者的自觉性，大大提升了集群的整体安全性。
通过STRIDE模型，我们系统地审视了Kubernetes可能面临的各种威胁，并探讨了相应的防御策略。安全是一个持续的过程，需要我们在架构设计、应用开发和日常运维的每个环节都保持警惕。记住，构建一座坚固的城堡，需要我们像一个深谋远虑的建筑师一样，提前规划好每一道防线。