【Kubernetes安全系列第二篇】kubernetes基础设施的安全

【Kubernetes安全系列第二篇】kubernetes基础设施的安全

原文

在我们开始保护kubernetes平台安全的任务之前，《Securing Kubernetes for Cloud Native Applications》系列的第一篇文章中，讨论了为什么很难保护Kubernetes，以及需要我们注意的各个层的概述。

堆栈中的第一层是基础架构层。 我们可以通过许多不同的方式对此进行定义，但出于讨论的目的，它是基于Kubernetes部署的基础架构组件的总和。 它是用于计算，存储和网络目的的物理或抽象硬件层，以及这些资源所处的环境。 它还包括操作系统（很可能是Linux）和容器运行时环境（如Docker）。

我们将要讨论的大部分内容同样适用于支持Kubernetes以外的系统的基础设施组件，但我们将特别关注那些可以增强Kubernetes安全性的因素。

机器，数据中心和公共云

采用云平台作为工作负载部署的工具，无论是公共，私有还是混合组合，都在继续快速发展。 虽然对专业裸机服务器配置的需求尚未完全消失，但支撑当今大部分计算资源的基础设施是虚拟机。 但是，如果我们部署的机器是虚拟的（基于云的或其他）或物理的，实体将驻留在由我们自己的组织或选定的第三方托管的数据中心，例如公共云提供商，这并不重要。

数据中心很复杂，在考虑安全性方面需要考虑很多。 它是托管整个组织的数据处理要求的一般资源，甚至是来自不同行业和地区的众多独立组织的共同租用工作负载。 出于这个原因，在这个级别上对基础设施的许多不同方面应用安全性，往往是一个成熟的公司或供应商的责任。 它将根据诸如国家或国际法规（HIPAA，GDPR），行业合规要求（PCI DSS）等因素进行管理，并且通常会获得认证标准认证（ISO 27001，FIPS）。

在公共云环境的情况下，供应商可以并且将在基础设施层提供必要的遵守法规和合规标准，但在某些时候，它会下沉到服务消费者（您和我），以进一步构建这个安全的基础。 这是一项共同的责任。 这引出了一个问题，作为一个公共云服务消费者，“我应该保护什么，我该怎么做呢？”有很多人对这个话题有很多不同的看法，但是真正可靠的实体是互联网安全（CIS），一个致力于保护公共和私人实体免受恶意网络活动威胁的非营利组织。

CIS基准测试

CIS提供了一系列工具，技术和信息，用于对抗我们所依赖的系统和数据的潜在威胁。 例如，CIS基准是安全专业人员和主题专家共同编制的针对每个平台安全的最佳实践配置指南。 为了鼓励越来越多的组织开始实施转型计划，其中包括迁移到公共和/或混合云基础架构，CIS开展了对应的业务，为主要的公共云提供商提供基准。 CIS Amazon Web Services Foundations Benchmark就是一个例子，其他主要公共云提供商也有类似的基准。

这些基准测试提供基础安全配置建议，包括身份和访问管理（IAM），入口和出口，以及日志和监视最佳实践等。 实施这些基准建议是一个很好的开始，但它不应该是旅程的终点。 每个公共云提供商都有自己的一套详细的推荐最佳实践[^1] [^2] [^3]，并且可以从相关领域中的其他专家声音中获得很多好处，例如云安全联盟。

让我们花一点时间来看一下典型的基于云的场景，需要从安全角度进行一些仔细的规划。

云场景：专用网 vs 公有网

我们如何通过限制访问来平衡保持Kubernetes集群安全的需求，同时通过Internet以及我们自己的组织内部外部客户端实现所需的访问？

service.beta.kubernetes.io/aws-load-balancer-internal：0.0.0.0/0

此方案表明需要仔细考虑如何保证基础架构配置的安全，同时提供向其目标受众提供服务所需的功能。 这不是一个特殊的场景，还有其他情况需要类似的处理。

锁定目标：操作系统和容器运行时

假设我们已经调查并应用了必要的安全配置以使机器级基础架构及其环境安全，那么下一个任务是锁定每台机器的主机操作系统（OS），以及负责管理容器生命周期的容器运行时。

Linux OS

虽然可以将Microsoft Windows Server作为Kubernetes工作节点的操作系统运行，但控制平面和工作节点通常会运行 Linux 操作系统的变体。 可能有许多因素决定使用Linux发行版（商业，内部技能，操作系统成熟度），但如果可能的话，请使用专为运行容器而设计的最小发行版。 比如CoreOS Container Linux，Ubuntu Core和Atomic Host变体。 这些操作系统已经被剥离到最低限度以便于大规模地运行容器，因此具有显著减小的攻击面。

同样，CIS为不同风格的Linux提供了许多不同的基准，为保护操作系统提供了最佳实践建议。 这些基准涵盖了可能被认为是Linux的主流发行版，例如RHEL，Ubuntu，SLES，Oracle Linux和Debian。 如果未涵盖您的首选发行版，则存在独立发行版的CIS基准测试，并且通常存在特定发行版的准则，例如CoreOS容器Linux强化指南。

Docker Engine

基础结构中的最后一个组件是容器运行时。 在Kubernetes的早期，没有选择; 容器运行时必然是 Docker 引擎。 然而，随着Kubernetes容器运行时接口的出现，可以删除Docker引擎依赖性，转而使用CRI-O，containerd或Frakti等运行时。事实上，从Kubernetes 1.12开始，这是一个alpha功能（运行时），允许在集群中并行运行多个容器运行时。 无论部署哪个容器运行时，它们都需要被保护。

尽管选择多种多样，但Docker引擎仍然是Kubernetes的默认容器运行时（尽管在不久的将来可能会改变为containerd^4），我们将在此考虑其安全性含义。 它是使用大量可配置的安全设置构建的，其中一些默认情况下是打开的，但可以在每个容器的基础上绕过它们。 其中一个例子是在创建时应用于每个容器的Linux内核功能的白名单，这有助于减少正在运行的容器内的可用权限。

CIS再一次为Docker平台CIS Docker Benchmark保留了基准。 它提供了有关配置Docker守护程序以获得最佳安全性的最佳实践建议。 甚至还有一个方便的开源工具（脚本），名为Docker Bench for Security，可以针对Docker引擎运行，该引擎评估系统是否符合CIS Docker Benchmark。 可以定期运行该 工具 以暴露所需配置的任何漂移。

Docker被用作Kubernetes的容器运行时，在考虑和测量Docker引擎的安全配置时，需要注意一些事项。 Kubernetes忽略了Docker守护程序的许多可用功能，而是更喜欢自己的安全控件。 例如，Docker守护程序配置为使用seccomp配置文件将可用Linux内核系统调用的默认白名单应用于每个创建的容器。 除非另有说明，否则Kubernetes将指示Docker从seccomp角度创建pod容器“unconfined”，使容器可以访问每个可用的系统调用。 换句话说，可以在较低的“Docker层”配置的内容可能会在平台堆栈中的更高级别被撤消。 我们将在以后的文章中介绍如何通过安全上下文缓解这些差异。

总结

将所有注意力集中在平台的Kubernetes组件的安全配置上可能很诱人。 但正如我们在本文中看到的那样，较低层的基础架构组件同样重要，并且非常危险的是它们往往被被忽略。 实际上，提供安全的基础架构层甚至可以缓解我们可能在集群层本身中引入的问题。 例如，保持我们的节点私密性将防止不充分安全的kubelet被用于恶意目的。 基础设施组件应该与Kubernetes组件本身一样受到关注。

在下一篇文章中，我们将继续讨论安全堆栈中下一层的含义，即Kubernetes集群组件。

[^1]: AWS Security Best Practices

[^2]: Azure security best practices and patterns

[^3]: Best practices for enterprise organizations  |  Google Cloud