作者 | Sean Bangalore 译者 | Luga Lee 策划 | Luga Lee
Kubernetes 使得扩展基础架构变得容易，但它同时也带来了新的安全挑战。因此，在本文中我们将了解 K8s 安全性的最佳实践。
自 2014 年发布以来，Kubernetes 已经改变了 DevOps。我们不仅可以像在虚拟化部署中一样访问硬件和资源分配管理，而且现在，还可以访问托管运行时、更新和可移植性。Kubernetes 可以轻松启动和扩展，而无需担心编排。
大多数组织都意识到这些好处。在一项调查中，超过 50% 的参与者表示他们使用 Kubernetes 进行容器管理，并且 Kubernetes 和托管 Kubernetes 服务的受欢迎程度继续快速增长。
然而，Kubernetes 的采用也有其不利的一面。在 RedHat 的一项调查中，超过 94% 的受访者表示他们曾遭遇过容器安全事件。在上下文中考虑这一点并加强 Kubernetes 部署以抢占此类安全问题非常重要。
在本文中，我将简要介绍 Kubernetes 体系及其核心组件。然后，再深入探讨 Kubernetes 安全的“4C”框架，并介绍一些主动解决安全漏洞的策略。
Kubernetes 及其组件
要了解 Kubernetes 的安全性，我们需要深入学习 Kubernetes 在高层次上是如何工作的。每个 Kubernetes 环境都是松散耦合和分布的，因此如果一个环境受到损害，其他环境相对而言不会受到影响。但是，仍然存在需要管理的重大风险。
Kubernetes 环境的两个部分是控制平面和节点组件。控制平面托管 API 服务和 Kube 控制器管理器、键值存储以及调度程序等。
在控制平面内，有四个组件通过中心辐射模式连接。
- Kube Scheduler 将 Kube Pod 分配给节点；
- Etcd Key-Value Store保存集群数据（包括配置、状态和元数据）；
- Kube-Controller Manager 运行控制器进程，例如作业和节点控制器；
- Cloud-Controller Manager 与选择的云提供商建立连接。
每个节点组件都包括 Kubelet 和 Kube-proxies：
- Kubelet 确保容器运行且健康；
- Kube-proxy 在节点上维护网络规则，允许从集群内外的网络会话与 Pod 进行通信。
考虑到这种架构，让我们探索一些适用于 Kubernetes 环境的安全最佳实践。
安全架构、关注点和最佳实践
虽然每个 Kubernetes 组件是分开的，但还是要考虑控制平面和节点工作器之间的通信以及控制平面本身的安全性。毕竟，其在很大程度上受配置和实践的影响。
因此，可以在 Kubernetes 安全性的 4C 上下文中考虑安全性：云、集群、容器和代码。
我们可以把它们想象成俄罗斯套娃，每一层（“C”）都建立在它所包含的层的安全问题之上，并且容易受到其安全问题的影响。因此，代码层容易受到容器、集群和云中的安全问题的影响。
因此，为了保护代码和应用程序数据，需要保护所有四个层——云、集群、容器和代码。
Kubernetes 安全 4C 的最佳实践
在这四个层中有两个主要领域需要保护：可配置的集群组件和在集群中运行的应用程序。在接下来的部分中，我将介绍这两个领域中所有四个层的一些最佳实践。
代码
我不会涵盖编写安全软件代码的所有最佳实践，因为这是一个巨大的话题。但 Kubernetes 管理员主要需要担心网络通信和攻击预防措施。
网络
网络描述了应用代码如何连接到外部服务。我们可以通过保护服务之间的通信来减少攻击者可以访问应用系统的媒介。
以下是一些建议：
1、TCP 上的网络通信应设置为执行 TLS 握手并在默认情况下进行加密。可以使用在每个节点上运行的第三方服务网格；考虑 Istio、Linkerd、Consul 和 Citrix。
2、加密服务之间的通信。
3、只公开对通信和网络收集至关重要的端口。
攻击预防
除了保护通信安全外，还可以实施常规操作实践，扫描代码或内部配置以查找漏洞。可能会考虑的一些策略包括：
1、安排渗透测试以先发制人地防御 SQL 注入、CSRF 和 XSS 攻击——在开源社区中解决这些问题的流行工具是 Project ZAP。
2、通过至少一种静态分析工具（例如 kube-score）分析代码中的漏洞，例如，对 3rd 方依赖项的更新和更改以及不安全的编码实践。
对库和错误代码的更改可能会引入可能影响代码库安全性的错误和后门。自动监控有助于确保库是安全的，并且在部署之前检测到常见错误。
容器
通常，应用代码与配置文件、库和依赖项捆绑在一起运行于容器中。容器有一些重要的 Kubernetes 安全注意事项：
1、选择容器镜像/运行时时，选择隔离性更强的运行时类。Kubernetes 不会在运行时防止攻击，并且默认情况下不会检测映像中的问题。
2、作为构建步骤的一部分，扫描已知漏洞并签署容器映像。
3、仅允许容器之间（在 Pod/集群中）进行必要的通信，并限制对特定要求的特权访问。
使用来自私有注册表的已知容器也是一个好主意，但请记住，映像通常构建在也可能存在漏洞的外部基础层上。
集群
集群是 Pod 组中的容器。对于集群，维护控制平面的安全性很重要，特别是：
1、限制集群对 Etcd 后端的访问（如果需要升级权限，只能手动访问 Etcd）。大量敏感数据和权限驻留在 Etcd 上，因此除非绝对必要，否则我们不希望集群的其余部分能够访问它。
2、启用审计日志并将审计存档在安全服务器上，以便在调试期间进行监控和分析。
3、加密静态机密，以便攻击者在突破我们的集群防御时无法访问关键信息。
云
Kubernetes 集群通常在谷歌、亚马逊和微软等云提供商上运行。每个提供商都有我们应该实施的最佳实践的文档：
1、Amazon Web Services EKS Best 最佳实践；
2、Microsoft Azure；
3、Google Cloud Services。
虽然提供商会处理云中大多数高级别的安全问题，但仍然必须注意权限和访问控制。适用于所有云托管服务的一些注意事项包括：
1、提供对云资源的最低特权访问。
2、通过 kubectl-who-can 等来源使身份验证角色特定并审核对资源的访问：https://github.com/aquasecurity/kubectl-who-can
3、永远不要在 Docker 中嵌套 Docker 或以 root 身份运行进程。
4、定期运行 Kube-bench 以符合 CIS Kubernetes 基准。
如果不使用云，而是依赖内部服务器，则这一层的安全性会变得更加复杂，因为还需要考虑物理安全性和故障转移等问题。
安全的 Kubernetes 基本配置
开始使用 Kubernetes 时，会为业务所处的环境进行基本配置。但是，这些本质上并不安全。通常，可以做几件事来进一步保护我们的 Kubernetes 基本配置，包括：
1、监控图像的来源，并注意第三方图像注册表。DockerHub 是查找官方镜像的好地方。
2、仔细定义网络策略。 它们允许所指定内部和外部服务可以连接哪些实体，但默认情况下未定义入口和出口规则。
3、通过严格控制访问和明确定义的角色，根据需要保持用户安全权限。
4、在所选择的安全扫描器中使用未知修复标记关键问题和已识别的安全问题； 发布修复程序后，请返回已识别的安全问题。
监控和日志在安全中的作用
很难快速实施所有这些建议。密切关注 Kubernetes 和 4C 级别的默认设置需要不断增加的考虑事项列表。即使遵循所有这些最佳实践，内部和外部的变化也会不断引入新的漏洞，因此挑战永远不会真正结束。
这导致了我的最终建议，即实施强大的日志记录和监控。通过访问 Kubernetes 事件、日志和警报，我们可以在问题失控之前缓解问题。
ContainIQ 等工具可以帮助维护安全并确保及时响应风险。ContainIQ 可让我们轻松跟踪和管理 Kubernetes 事件、监控 Kubernetes 集群的运行状况，并通过其预先构建的仪表板、指标和数据馈送进行更多操作。
随着继续将 Kubernetes 集成到不断增长的组织中，请尽量不要成为 94% 在部署中遇到安全漏洞的组织的一部分。考虑上面的安全最佳实践，并留意变化，因为 Kubernetes 是一个积极发展的生态系统。
- EOF -
