在 Kubernetes 中安全地运行工作负载是很困难的,有很多配置都可能会影响到整个 Kubernetes API 的安全性,这需要我们有大量的知识积累来正确的实施。Kubernetes 在安全方面提供了一个强大的工具 securityContext
,每个 Pod 和容器清单都可以使用这个属性。在本文中我们将了解各种 securityContext
的配置,探讨它们的含义,以及我们应该如何使用它们。
securityContext
设置在 PodSpec
和ContainerSpec
规范中都有定义,这里我们分别用[P]
和[C]
来表示。需要注意的是,如果一个设置在两个作用域中都可以使用和配置,那么我们应该优先考虑设置容器级别的。
1. 为容器配置 Security Context
大部分情况下容器不需要太多的权限,我们可以通过 Security Context
限定容器的权限和访问控制,只需加上 SecurityContext 字段:
2. 禁用 allowPrivilegeEscalation
allowPrivilegeEscalation=true
表示容器的任何子进程都可以获得比父进程更多的权限。最好将其设置为 false,以确保 RunAsUser
命令不能绕过其现有的权限集。
3. 不要使用 root 用户
为了防止来自容器内的提权攻击,最好不要使用 root 用户运行容器内的应用。UID 设置大一点,尽量大于 3000
。
4. 限制 CPU 和内存资源
这个就不用多说了吧,requests 和 limits 都加上。
5. 不必挂载 Service Account Token
ServiceAccount 为 Pod 中运行的进程提供身份标识,怎么标识呢?当然是通过 Token 啦,有了 Token,就防止假冒伪劣进程。如果你的应用不需要这个身份标识,可以不必挂载:
7. 限制容器的 capabilities
容器依赖于传统的 Unix 安全模型,通过控制资源所属用户和组的权限,来达到对资源的权限控制。以 root 身份运行的容器拥有的权限远远超过其工作负载的要求,一旦发生泄露,攻击者可以利用这些权限进一步对网络进行攻击。
默认情况下,使用 Docker 作为容器运行时,会启用 NET_RAW
capability,这可能会被恶意攻击者进行滥用。因此,建议至少定义一个PodSecurityPolicy
(PSP),以防止具有 NET_RAW 功能的容器启动。
通过限制容器的 capabilities,可以确保受攻击的容器无法为攻击者提供横向攻击的有效路径,从而缩小攻击范围。
如果你对 Linux capabilities 这个词一脸懵逼,建议去看看我的脑残入门系列:
- 👉Linux Capabilities 入门教程:概念篇
- 👉Linux Capabilities 入门教程:基础实战篇
- 👉Linux Capabilities 入门教程:进阶实战篇
8. 只读
如果容器不需要对根文件系统进行写入操作,最好以只读方式加载容器的根文件系统,可以进一步限制攻击者的手脚。