Kubernetes每一层安全的最佳实践

雨点打透心脏的1/2处 2023-01-20 05:56 7阅读 0赞

**目录**

第0层–内核

第1层–容器

静态

运行

第2层–工作负载（Pod）

第3层–网络

应用层（L7）攻击–服务器端请求伪造（SSRF）

应用层（L7）攻击–远程执行代码（RCE）

应用层（L7）防御

第4层-节点

第5层–集群组件

--------------------

![4c0126a993ea4289c0a3cb802c08a9ff.png][]

容器正在改变软件开发。作为CI/CD的新基础，容器为你提供了一种快速，灵活的方式来部署应用程序，API和微服务，而数字化成功与否取决于可扩展性和性能。但是，容器和容器编排工具（例如Kubernetes）也是黑客们的热门目标，如果它们没有得到有效的保护，它们可能会使你的整个环境面临风险。在本文中，我们将讨论容器堆栈每一层安全的最佳实践。

了解容器安全的含义很重要。作为依赖共享内核的应用程序层构造，容器可以比VM更快地启动。在配置方面，容器也比VM灵活得多，并且可以执行挂载存储卷到禁用安全功能的所有操作。

如果绕过容器隔离机制并在主机上获得特权时，该容器甚至可以在黑客的控制下以root用户身份运行，然后你就陷入了真正的麻烦。

你可以采取一些措施，将坏蛋拒之门外。

## 第0层–内核 ##

Kubernetes是一个开源平台，旨在自动执行容器的部署，扩展和编排，正确配置它可以帮助你增强安全性。在内核级别，你可以：

*  查看允许的系统调用，并删除所有不必要或不需要的系统调用
 *  使用[gVisor][]或[Kata Containers][]等容器沙箱进一步限制系统调用
 *  验证你的内核版本已打补丁并且不包含任何现有漏洞

## 第1层–容器 ##

### 静态 ###

静态的容器安全性侧重于将用于构建容器的Docker镜像。首先，通过删除不必要的组件，程序包和网络实用程序来减少容器的攻击面-精简越多越好。考虑使用[仅][Link 1]包含应用程序及其运行时依赖项的 [distroless][Link 1]镜像。

> Distroless ([https://github.com/GoogleCloudPlatform/distroless][https_github.com_GoogleCloudPlatform_distroless]) 是谷歌内部使用的镜像构建文件，包括 Java 镜像，Node，Python 等镜像构建文件，Distroless 仅仅只包含运行服务所需要的最小镜像，不包含包管理工具，shell 命令行等其他功能。

接下来，确保仅从已知可信任的来源中提取镜像，然后扫描它们中的漏洞和配置错误。在你的CI/CD流水线和构建过程中检查它们的完整性，并在运行之前进行验证和批准，以确保黑客未安装任何后门程序。

### 运行 ###

打包镜像后，就该进行调试了。临时容器将使你可以交互式地调试运行中的容器。监视异常和可疑的系统级事件，这些事件可能是破坏的迹象，例如，产生了意外的子进程，在容器内运行的shell或意外读取了敏感文件。

开源运行时安全工具Falco可以为你提供帮助，它通过以下方式使用系统调用来保护和监视系统：

*  在运行时从内核解析Linux系统调用
 *  针对强大的规则引擎声明流
 *  违反规则时发出警报

## 第2层–工作负载（Pod） ##

Pod是Kubernetes内的部署单位，是容器的集合，可以共享常见的安全定义和对安全敏感的配置。[Pod安全上下文][Pod]可以设置给定[Pod][]的特权和访问控制，例如：

*  容器内的特权容器
 *  进程和卷的组和用户ID
 *  细粒度的Linux功能（删除或添加），例如Sys.time
 *  沙箱和强制访问控制（seccomp，AppArmor，SELinux）
 *  文件系统权限
 *  特权升级

为了加强Pod级别的防御能力，你可以实施严格的Pod安全策略，以防止危险的工作负载在集群中运行。要获得对Pod安全性的更大灵活性和更精细的控制，请考虑使用[OPA Gatekeeper项目][OPA Gatekeeper]实施的[开放策略代理（OPA）][OPA]。

## 第3层–网络 ##

默认情况下，所有Pod都可以不受限制地与集群中的所有其他Pod对话，这从攻击者的角度来看非常有利。如果工作负载受到威胁，攻击者可能会尝试探测网络并查看他们还可以访问什么。Kubernetes API也可以从Pod内部访问，从而提供了另一个丰富的目标。

严格的网络控制是容器安全的关键部分-pod到pod，集群到集群，由内而外和由内而外。使用内置的网络策略来隔离工作负载通信并构建精细的规则集。考虑实现服务网格以控制工作负载之间的流量以及入口/出口，例如通过定义namespace到namespace的流量。

### 应用层（L7）攻击–服务器端请求伪造（SSRF） ###

最近，我们已经听到很多关于SSRF攻击的消息，这也就不足为奇了。在API与其他API对话的云原生环境中，SSRF尤其难以防御。webhooks尤其臭名昭著。一旦找到目标，就可以使用SSRF升级特权并扫描本地Kubernetes网络和组件，甚至在Kubernetes指标端点上转储数据，以了解有关环境的有价值的信息-并有可能将其完全接管。

### 应用层（L7）攻击–远程执行代码（RCE） ###

RCE在云原生环境中也非常危险，这使得在容器内运行系统级命令来抓取文件，访问Kubernetes API，运行镜像处理工具以及破坏整个机器成为可能。

### 应用层（L7）防御 ###

保护的第一条规则是遵守安全的编码和体系结构实践，这可以减轻你的大部分风险。除此之外，你还可以沿两个方向对网络防御进行分层：南北方向，以监视和阻止针对你的应用程序和API的恶意外部流量；东西方向，以监视从一个容器到另一个容器，从一个集群到另一个集群以及从云到云的流量，以确保你不会受到受损的Pod的伤害。

## 第4层-节点 ##

节点级安全性同样重要。为防止容器在VM或其他节点上爆发，请限制对节点以及控制平面的外部管理访问，并注意开放的端口和服务。使基本操作系统保持最少，并使用[CIS基准][CIS]对其进行加固。最后，确保像其他任何VM一样扫描和修补节点。

## 第5层–集群组件 ##

Kubernetes集群中发生了各种各样的事情，并且没有保护它的多合一工具或策略。在较高的级别上，你应该专注于：

*  **API服务器**–检查你的访问控制和身份验证机制，并对动态Webhooks，Pod安全策略以及对Kubernetes API的公共网络访问执行其他安全检查；
 *  **访问控制**\-使用基于角色的访问控制（RBAC）对API服务器和Kubernetes secret实施最低特权原则
 *  **服务帐户令牌**–为了防止未经授权的访问，请限制对服务帐户以及存储服务帐户令牌的所有secret的权限
 *  **审核日志记录**\-确保已启用
 *  **第三方组件**–注意带入集群中的内容，以便知道集群中正在运行的内容以及原因
 *  **Kubernetes版本**– Kubernetes可以像任何其他系统一样具有漏洞，并且必须及时进行更新和修补。
 *  **Kubelet配置错误**–负责容器编排以及与容器运行时的交互，Kubelet可能会被滥用和攻击，以试图提升特权

Kubernetes的安全性似乎令人望而生畏，但是通过在堆栈的每一层上遵循最佳实践，可以使容器与环境达到相同的高级别保护。因此，你可以享受快速，敏捷的开发带来的好处。

译文链接：[https://thenewstack.io/defend-the-core-kubernetes-security-at-every-layer/][https_thenewstack.io_defend-the-core-kubernetes-security-at-every-layer]

[4c0126a993ea4289c0a3cb802c08a9ff.png]: /images/20221021/881fb61e9f56407a92c884cde84561f6.png
[gVisor]: https://gvisor.dev/
[Kata Containers]: https://katacontainers.io/
[Link 1]: https://github.com/GoogleContainerTools/distroless
[https_github.com_GoogleCloudPlatform_distroless]: https://github.com/GoogleCloudPlatform/distroless
[Pod]: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
[OPA Gatekeeper]: https://github.com/open-policy-agent/gatekeeper
[OPA]: https://www.openpolicyagent.org/
[CIS]: https://www.cisecurity.org/cis-benchmarks/
[https_thenewstack.io_defend-the-core-kubernetes-security-at-every-layer]: https://thenewstack.io/defend-the-core-kubernetes-security-at-every-layer/