doc_security.md

K8s安全分析

声明，本篇文章的内容主要来自Kubernetes修炼手册 @Nigel Poulton。

1. 安全模型

本文采用STRIDE模型来对K8s进行安全分析，该模型定义了6种潜在威胁：

• 伪装
• 篡改
• 抵赖
• 信息泄露
• 拒绝服务
• 提升权限

下文将对这些威胁进行详细分析。

2. 伪装

在信安领域，伪装指攻击者为了获得更多的系统权限而冒充另一个人或主体。

2.1 与API Server的安全通信

K8s是一个由多个组件构成的系统，它们包括：

• API Server（Pod）
• Controller manager（Pod）
• Scheduler（Pod）
• Store（etcd）
• kube-proxy（Pod）
• kubelet（journald）

以上这些组件基本上都是与API Server进行通信的，K8s在组件通信之间采用了Mutual TLS（mTLS）认证。 这要求通信双方都要提供自己的证书给对方进行身份验证，这种方式区别于传统的单向证书认证（仅限于客户端验证服务端）。

K8s内部通过自旋证书来简化了mTLS的实现。简单来说，K8s部署时自动生成了一个自签名的CA，这个CA将用来为集群内的所有组件颁发证书。 所以mTLS的安全性依赖于CA的可靠性，CA私钥的泄露将导致整个集群组件之间的通信彻底陷入危险。 除此之外，还需要注意：

• CA证书仅在集群内使用
• 使用CA批准证书签名请求（CSR）时保持严谨
• 确保CA不会被系统外的任何组件设置为可信CA

此外，API Server还可能与集群外的组件进行通信（比如Webhook）。这时候推荐使用两套不同的可信秘钥——分别用于认证内部组件和外部组件。 要实现这一点，K8s需要将一个集群外的CA添加为可信CA，然后对于集群外的组件，应当使用外部CA颁发的证书来与API Server进行通信。

2.2 Pod间的安全通信

Pod间通信的认证方式可以通过Service Account（SA）来实现。每个Pod启动时默认都会自动分配一个ServiceAccount作为Secret挂载到Pod中。 并且该SA是被允许访问API Server的，只是权限受限，但我们要知道，大多数Pod并不需要访问API Server。

所以，对于不需要与API Server通信的Pod，我们建议将Pod清单中的automountServiceAccountToken属性设置为false。 如果需要挂载SA，那么有些非默认的配置需要了解一下：

• expireSeconds：设置token有效期
• audience：限制token的受众

这些属性的具体示例，你可以在官方找到。

3. 篡改

篡改通常基于以下目的：

• 拒绝服务：篡改资源使其不可用
• 提高权限：篡改资源获取额外权限

3.1 对K8s组件的篡改

K8s系统内可以篡改的资源有以下几种：

• etcd
• 配置文件：API Server、ControllerManager、Scheduler、Kube-proxy和Kubelet
• 容器运行时的二进制
• 容器镜像
• K8s的二进制

篡改行为通常发生在（网络）传输和保存过程中。TLS可以确保数据的完整性，下面的建议有助于防范对保存在集群中数据的篡改攻击：

• 严格限制对运行由K8s组件的服务器的访问，尤其是部署了控制层组件的节点
• 严格限制对保存有K8s配置文件的库的访问
• 仅在最初部署K8s时进行ssh访问节点
• 对下载的二进制文件进行哈希验证
• 严格限制镜像仓库及相关库的访问

此外，建议在生产环境中对关键组件的二进制文件的审计和监控，相关的工具有auditctl等。

3.2 对于运行在K8s中的应用的篡改

推荐将Pod中容器的文件系统设置为只读是一种推荐的办法。我们可以在Pod的清单中设置securityContext.readOnlyRootFilesystem 属性为true， 也可以通过部署PodSecurityPolicy对象来全局性的限制所有Pod的文件系统的读写权限。

PodSecurityPolicy特性从v1.25开始被删除，转而使用Pod 安全性标准进行代替。

4. 抵赖

抵赖就是制造对某件事的不确定性。不可抵赖就是提供证据（以证实某事），具体来说应该能够证明以下信息：

• 发生了什么
• 什么时间发生的
• 谁操作的
• 在哪里发生的
• 为什么发生的
• 如何发生的

对于后两个信息，通常需要一段时间内的多个相关事件的信息。

K8s提供针对API Server的审计（Audit）功能来完成回答以上问题，该功能需要手动开启，请参考官方文档审计部分。

然而，除了API Server，K8s还提供了对其他组件的审计，比如容器运行时、Kubelet等各应用的审计日志。如果要收集多个组件的日志， 那么就需要一个中心化的日志后端来实现对事件的保存和分析。一种常见的做法是在每个节点上部署DaemonSet类型的日志代理来收集日志， 然后发送至中心日志数据库，同时要确保这个中心化的日志库是安全的。

5. 信息泄露

主要是指敏感数据的泄露。

5.1 保护集群数据

K8s中的所有集群配置都是保存在集群存储中的（目前是etcd），包含网络和存储配置以及Secret形式保存的密码登敏感数据。 这就使得集群存储会成为被攻击的首要目标。

我们必须对运行由集群存储的节点进行访问限制和审计。

5.2 保护Pod中的数据

前面提到，K8s提供了Secret对象来保存密码等敏感数据。但请注意，Secret是以未加密的形式存储在集群存储中的， 我们可以为其使用静态加密，请参考官方文档Secrets良好实践部分。

6. 拒绝服务

这种方式的攻击目的在于使服务不可用。在K8s中，拒绝服务的最大可能攻击对象就是API Server。

6.1 保护集群资源免于DoS攻击

首先，我们应该对主节点进行高可用（HA）部署。

进一步，我们还可以考虑将主节点部署在多个可用域中， 这样可以避免某个可用域的网络遭受故障导致整个集群不可用。这个防范原则也适用于工作节点。

此外，我们还应当为以下资源配置限额（参考ResourceQuota对象）：

• 内存
• CPU
• 存储
• K8s对象（ReplicaSet、Pod、Service、Configmap、Secret等）

添加配额限制有助于避免重要系统资源被消耗殆尽，从而提高抵御DoS的能力。

6.2 保护API Server防范DoS攻击

参考以下方法：

• 高可用部署主节点
• 对到达API Server的请求进行合理监控和预警
• 不将API Server暴露在互联网上（借助防火墙/安全组规则）

即使K8s拥有良好的鉴权机制，也需要注意妥善保管具有较高权限的账号。

6.3 保护集群存储防范DoS攻击

集群存储（etcd）的重要性已经不需要过多强调，参考一下方法加固etcd：

• 将etcd部署为3个或5个节点的集群
• 对etcd收到的请求进行监控和预警
• 在网络层面对etcd进行隔离，只允许控制平面组件与其交互

默认情况下，K8s会将etcd安装到与控制平面组件相同的节点上，对于非生产环境这是OK的。但是生产环境就不太合适了， 应该考虑为K8s单独部署一个etcd集群，有助于提高系统的性能和弹性。

在性能方面，etcd可能是大型K8s集群的瓶颈所在。所以在集群部署阶段应当进行适当的性能测试，以确保整体架构能够在较大规模下维持较高性能。 性能不足的etcd集群的表现基本等同于正在遭受DoS攻击的etcd集群。

6.4 保护应用组件防范DoS攻击

多数Pod会将其服务暴露于互联网之上，如果没有采取合理的控制，任何人都可以访问Pod并对其实施DoS攻击。 好在，K8s支持对Pod进行资源请求限制。推荐下面的安全措施：

• 对Pod之间和Pod与外部的通信配置网络安全策略以控制流量的出站/入站（NetworkPolicy）
• 利用mTLS和基于Token的API认证来提供（Pod层面）应用级的认证

7. 提升权限

7.1 保护API Server

K8s提供以下鉴权方式来保证API Server的安全性：

• RBAC（基于角色的访问控制）
• webhook
• 节点认证

建议同时开启多个鉴权机制。例如，一种常见的方式是同时启用RBAC和节点两种鉴权机制。

RBAC模式能够指限制哪个用户（组）能够对哪些资源执行哪些操作。Webhook模式则是将鉴权工作交给外部的基于REST接口的策略引擎来完成。 不过需要额外搭建和维护一套外部引擎，且这个引擎也可能会带来API Server的单点故障隐患，因为API Server会持续调用外部引擎来完成每一次鉴权。 所以一旦外部引擎宕机，则API Server无法继续完成请求。鉴于此，应该严格谨慎地对待webhook鉴权服务的设计与实现。

节点认证模式是指对来自kubelet的请求进行鉴权。对节点请求的鉴权工作由节点鉴权器（node authorizer）完成。

7.2 保护Pod

下面提供一些手段来显著降低以Pod和容器为目标的"提升权限"攻击的风险。

• 避免进程以root身份运行（通过PodSpec中的spec.securityContext.runAsUser，此属性还可以在容器层面进行配置）
  • 若Pod由不同容器组成，建议为不同容器配置不同用户，以避免容器之间互相干扰
• 限制capabilities
  • 在linux内部，root用户的权限是由不同的capabilities的权限组合而成的，比如，名为SYS_TIME的capability允许用户设置系统时钟。
  • NET_ADMIN允许用户执行网关相关操作（如修改本地路由表、配置本地接口）
  • root用户拥有所有的capability
  • 我们可以在配置非root用户的同时，为其添加capability来满足容器需求
• 过滤系统调用
  • Seccomp是linux自 2.6.12 以来一直是Linux 内核的一个特性。它可以用来沙箱化进程的权限，限制进程从用户态到内核态的调用。
• 避免权限提升
  • linux中允许子进程申请比父进程更多的权限。我们可以通过spec.securityContext.allowPrivilegeEscalation属性来禁止权限提升
• 配置selinux

这些功能配置基本都是通过spec.securityContext 属性来完成的。具体配置参考官方文档的为 Pod 或容器配置安全上下文。

Capabilities
如今linux-capabilities总共有30个，我们可以在spec.securityContext.capabilities 中配置容器所拥有的capabilities。

8. K8s安全展望

2019年CNCF委托了一个第三方机构对K8s进行了安全审计。通过安全威胁建模、人工代码审查、动态渗透测试和加密审查等方面的审计方法发现了一些安全隐患。 所有的隐患都给出了难度和严重程度级别。这次审查非常细致，本着负责人的态度，所有严重级别的隐患都在对外发布前被修复了。

不过，仍然有许多问题等待社区来解决。

9. 一些实践建议汇总

CI/CD流水线：

• 使用私有镜像仓库（或公共仓库如DockerHub中的私有repository）
  • 并且使用分离的repository（如开发、测试、生产）
• 使用已验证的基础镜像
• 控制镜像库的访问权限（push/pull）
  • 生产repo限关键用户拥有push权限
  • 限制用户进行push/pull镜像
  • 限制某些客户端节点能访问镜像库
• 整合漏洞扫描
  • 在扫描到镜像漏洞后自动令构建流水线失败
• 审查配置文件（Dockerfile、K8s YAML文件）
• 使用镜像签名，确保镜像完整性
  • push时添加签名，pull时验证签名

基础设施隔离：

• 使用K8s命名空间隔离工作负载
  • 对单一命名空间进行资源限额
  • 创建单独的用户管理特点的命名空间
• 节点隔离
  • 对于需要特殊权限（如root）运行的应用Pod，应将其部署到特定的节点（通过亲合度/污点/标签）
• 运行时隔离
  • 容器和虚拟机的隔离性是不同的
  • 多个容器会共享一个CPU内核，隔离性由内核指令提供。是一种软性隔离，不如虚拟机。
  • 虚拟机的隔离性由硬件虚拟化技术提供，每台虚拟机独享一个硬件CPU内核
  • 可以使用不同容器运行时（如gVisor和Kata）来提供更高级别的Pod隔离性
    • 首先为特定节点安装配置特定的容器运行时
    • 然后使用Runtime Class（K8s v1.20 stable）和nodeSelector将Pod调度到这类节点

网络隔离：

• K8s中的Pod网络通过CNI（Container Network Interface）实现，主流实现分为Overlay和BGP两类
• 使用K8s的网络策略（NetworkPolicy）来限制Pod之间的通信，支持跨命名空间

身份认证和访问控制管理：

• 充分使用RBAC系统
• 严格限制哪些人员能够ssh到控制平面节点的权限
• 部署审计和监控系统，应对未来某个时候被攻破的情况
• 安全配置
  • 在PodSpec中限制容器以非root身份运行
  • 信息安全中心（CIS）发布了一套针对K8s安全性的行业标准要求
  • Aqua Security公司编写了一个易于使用的K8s安全评估工具kube-bench来执行对节点的CIS要求的测试

审计和安全监控：

• 保留容器和Pod的生命周期事件
  • 通过采集每个节点上的容器运行时日志发送到外部存储（如ES），以便在未来调查问题时使用
• 采集每个节点上的Pod日志
• 记录每个节点上的命令执行，发送到日志中心（可以采用跳板机）

参考

• Kubernetes修炼手册 @Nigel Poulton