Kubernetes基础设施的安全
Kubernetes基础设施的安全
2020-02-07 18:22:10 来源：分布式实验室
抢沙发
2020-02-07 18:22:10 来源：分布式实验室
摘要：在我们开始保护Kubernetes平台安全的任务之前，《Securing Kubernetes for Cloud Native Applications》系列的第一篇文章中，讨论了为什么很难保护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 Amazon Web Services Foundations Benchmark[1]就是一个例子，其他主要公共云提供商也有类似的基准。
这些基准测试提供基础安全配置建议，包括身份和访问管理（IAM），入口和出口，以及日志和监视最佳实践等。实施这些基准建议是一个很好的开始，但它不应该是旅程的终点。每个公共云提供商都有自己的一套详细的推荐最佳实践，并且可以从相关领域中的其他专家声音中获得很多好处，例如云安全联盟。
让我们花一点时间来看一下典型的基于云的场景，需要从安全角度进行一些仔细的规划。
我们如何通过限制访问来平衡保持Kubernetes集群安全的需求，同时通过Internet以及我们自己的组织内部外部客户端实现所需的访问？
-
对托管Kubernetes的计算机使用专用网络：确保代表集群节点的主机没有公共IP地址。 移除与任何主机直接连接的能力，显著减少了可被用来攻击的选项。 例如，这种简单的预防措施提供了显而易见的好处，可以防止可能导致利用加密货币挖矿的种种妥协。
-
使用堡垒主机访问专用网络：应通过适当配置的堡垒主机提供管理集群所需的对主机专用网络的外部访问。 Kubernetes API通常也会暴露在堡垒主机后面的专用网络中。 当然，它也可能公开发布，但建议至少通过组织内部网络和/或其VPN服务器的白名单IP地址来限制访问。
-
将VPC peering与内部负载均衡/DNS一起使用 - 其中在具有专用网络的Kubernetes集群中运行的工作负载需要由其他私有的集群外客户端访问，工作负载可以通过调用内部负载均衡的服务公开。 例如，要在AWS环境中创建内部负载均衡，该服务需要以下注释：service.beta.kubernetes.io/aws-load-balancer-internal：0.0.0.0/0。 如果客户端驻留在另一个VPC中，则需要VPC peering。
-
使用具有Ingress的外部负载均衡 - 工作负载通常设计为由来自Internet的匿名外部客户端使用；当部署到专用网络时，如何允许流量在集群中查找工作负载？我们可以通过几种不同的方式实现这一目标，具体取决于手头的要求。第一种选择是使用Kubernetes服务对象公开工作负载，这将导致在公有子网上创建外部云负载平衡器服务（例如，AWS ELB）。这种方法可能非常昂贵，因为每个公开的服务都会调用专用的负载均衡，但可能是非HTTP服务的首选解决方案。对于基于HTTP的服务，更具成本效益的方法是将ingress controller部署到集群，前面是Kubernetes服务对象，后者又创建了负载均衡器。在进一步路由到匹配规则中的服务端点之前，寻址到负载均衡的DNS名称的流量被路由到ingress controller端点，该端点评估与任何定义的Ingress对象相关联的规则。
此方案表明需要仔细考虑如何保证基础架构配置的安全，同时提供向其目标受众提供服务所需的功能。 这不是一个特殊的场景，还有其他情况需要类似的处理。
假设我们已经调查并应用了必要的安全配置以使机器级基础架构及其环境安全，那么下一个任务是锁定每台机器的主机操作系统（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强化指南[2]。
基础结构中的最后一个组件是容器运行时。在Kubernetes的早期，没有选择；容器运行时必然是Docker引擎。然而，随着Kubernetes容器运行时接口的出现，可以删除Docker引擎依赖性，转而使用CRI-O，containerd或Frakti等运行时。事实上，从Kubernetes 1.12开始，这是一个alpha功能（运行时），允许在集群中并行运行多个容器运行时。无论部署哪个容器运行时，它们都需要被保护。
尽管选择多种多样，但Docker引擎仍然是Kubernetes的默认容器运行时（尽管在不久的将来可能会改变为containerd），我们将在此考虑其安全性含义。它是使用大量可配置的安全设置构建的，其中一些默认情况下是打开的，但可以在每个容器的基础上绕过它们。其中一个例子是在创建时应用于每个容器的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组件本身一样受到关注。
第三十四届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：chenjian
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
