Kubernetes 安全防护终极指南
终极指南 K安u全be防rn护etes 如流何水保线护Kubernetes 安 终极指南 K如何u保b护eKurbnerenettees流s水线 目录 全防护 保护容器部署安全的重要意义3 Kubernetes的运行机制6 Kubernetes漏洞和攻击载体9 保护整个流水线12 CI/CD生产线安全防护13 Kubernetes节点生产准备14 Kubernetes运行时容器安全防护15 Kubernetes系统和资源安全防护18 Kubernetes环境的审核与合规——安全态势20 应用的运行时安全防护——NEUVECTOR容器安全平台22 Kubernetes安全防护自动化——这可能吗？28 满足PCI、GDPR、SOC2、HIPAA、NIST合规性要求30 开源Kubernetes安全防护工具32 运行时Kubernetes安全防护检查清单34 2 保护容器部署安全的重要意义 借助容器和Kubernetes等工具，企业能够在应用程序部署的诸多方面实现自动化，继而获得巨大的业务收益。但这些新的部署环境与传统环境一样，容易受到黑客和内部攻击者的攻击和利用。私有云和公有云中基于容器的新型虚拟化环境仍会受到勒索软件、非法加密挖矿、数据窃取和服务中断等形式的攻击。 更麻烦的是，公有云中的Kubernetes等新型工具和技术以及托管容器服务本身就将为攻击企业的重要资产提供可乘之机。继近期Kubernetes的中间人漏洞和Tesla漏洞事件之后，许多攻击者都蠢蠢欲动，等待时机针对容器技术发起攻击，预计这类事件将在未来几个月乃至多年内频繁发生。 容器高度动态化的特征带来了下列安全挑战： 1.CI/CD流水线引入的漏洞。开源组件的大量运用和不断涌现的严重漏洞都会在构建阶段、注册表和生产过程中对容器镜像产生影响。 2.东西向流量激增。虽然可以通过传统的防火墙和主机安全防护工具来保护单片应用程序，但容器可能使东西向流量或内部流量持续增加，因此必须对这些流量进行攻击监控。 3.攻击面扩大。每个容器中都含有可能被利用的不同攻击面和漏洞。此外，还必须将 Kubernetes和Docker等编排工具引入的其他攻击面考虑在内。 4.自动化安全防护才能满足发展需要。以往的安全防护模型和工具无法应对不断变化的容器环境。考虑到Kubernetes自动化的性质，容器和Pod从出现到消失可能只有几分钟甚至几秒的时间。可能包含新网络连接的应用程序行为必须即时纳入强制安全策略中。我们需要通过新一代自动化安全工具来保护容器安全，在流水线前期声明安全策略，并通过代码形式进行管理。 有些人提出，由于功能和专用接口有限，默认情况下容器比传统应用程序更安全，但这种观点仅在以下情况中成立：网络攻击者和公共部门攻击者使用旧有手段攻击没有漏洞且已锁定所有潜在威胁载体的代码和基础设施。但我们清楚，这在现实中是不可能的。而且即便如此，也仍然需要实时对攻击进行监控。攻击事件屡次发生，时间和经验都表明，攻击者的手段总是能够击破乃至超越新的基础设施策略。恶意攻击者将不断开发全新手段来攻击容器。 KUBERNETES团队的安全防护能力自查： •团队是否具备能在流水线前期甚至构建阶段消除重大漏洞（具有可用修补程序）的相关流程？ •团队对正在部署的KubernetesPod是否具有可见性？例如，是否了解应用程序Pod 或集群之间如何通信？ •团队能否从容器间的东西向流量中检测出恶意行为？ •团队能否确定每个Pod的行为正常与否？ •当内部服务Pod或容器开始在内部扫描端口或尝试随机连接外部网络时，团队如何接收警报？ •团队如何确定攻击者是否已经在容器、Pod或主机中找到了切入点？ •团队能否像对于非容器化部署一样全面查看和检查网络连接？例如7层网络？ •如果面临潜在攻击，团队能否监控Pod或容器内部的活动情况？ •团队是否曾通过检查Kubernetes集群的访问权限来确定潜在的内部攻击载体？ •团队是否拥有锁定Kubernetes服务、访问控制(RBAC)和容器主机的检查清单？ •如果具备合规策略，如何在运行时执行以确保合规性？例如，确保内部Pod通信加密，当Pod未使用加密通道时团队将如何得知？ •在对应用程序通信进行故障排除或记录取证数据时，如何定位相关Pod并抓取日志？团队如何抓取原始流量，并在其消失前进行快速分析？ 这篇指南将重点围绕自动化运行时安全防护，介绍如何实现Kubernetes和容器部署的安全。 首先必须要了解Kubernetes的运行机制和网络连接的处理方式。 Kubernetes的运行机制 基本信息 如果还不熟悉Kubernetes，可以先来了解下列主要概念和术语。 Kubernetes是一种能够自动化部署、更新和监控容器的编排工具。RedHatOpenShift、DockerEE、SUSERancher、IBMCloud、AWSEKS、Azure、SUSECaaS和GoogleCloud等所有主流容器管理和云平台全部支持Kubernetes。下面是一些需要了解的Kubernetes相关概念： •主节点：管理Kubernetes工作节点集群和在节点上部署Pod的服务器。节点可以是物理机或虚拟机。 •工作节点：也称为从属节点或下属节点，这些服务器通常运行应用程序容器和代理等其他Kubernetes组件。 •POD：Kubernetes中的部署和可寻址性单元。每个Pod都拥有独立的IP地址，其中可能包含一个或多个容器（通常为一个）。 •服务：为其底层Pod和请求充当代理的服务功能，可在各复制Pod之间进行负载均衡。服务还可通过定义外部IP或节点端口来为一个或多个Pod提供外部访问端点。Kubernetes也提供DNS服务、路由程序和负载均衡器。 用于管理Kubernetes集群的主要组件包括API服务器、Kubelet和etcd。Kubernetes还支持基于浏览器的管理控制台——Kubernetes仪表盘（可选）。以上所有组件都是潜在的攻击目标。例如，Tesla漏洞事件就是一个未被保护的Kubernetes控制台被攻击，进而被安装了挖矿软件。 KUBERNETES基于角色的访问权限控制 Kubernetes基于角色的访问权限控制(RBAC)可实现资源的精细化管理。它能够提供对应用程序工作负载和Kubernetes系统资源的访问权限。OpenShift等管理工具可以添加其他功能，但需要依赖或使用原生Kubernetes基本安全控制。通过妥善配置访问权限控制来防止未经授权访问API服务器或应用程序工作负载等Kubernetes组件的行为至关重要。 KUBERNETES网络连接基本信息 Kubernetes的主要网络连接概念是：为每个Pod分配独立的可路由IP地址。Kubernetes （实际上是其网络插件）负责在内部将主机之间的所有请求路由至相应的Pod。KubernetesPod的外部访问权限可通过服务、负载均衡器或入口控制器来提供，Kubernetes会将其路由至相应的Pod。 Kubernetes使用iptables来控制Pod（和节点）之间的网络连接，以及处理大量的网络连接和端口转接规则。这样一来，客户就不需要追踪连接至Kubernetes服务的IP地址。而且，由于各个Pod都有独立的IP地址，并且其容器能够侦听原生端口，因此端口映射得到了大大简化（大部分被省略）。 鉴于所有这类Overlay网络连接都由Kubernetes动态处理，所以监控网络流量的难度极大，安全防护更是难上加难。以下是Kubernetes网络连接运行方式的示例。 POD1 192.168.20.21 POD2 192.168.56.193 src:192.168.20.21 dst:192.168.56.193 Routingtable: 192.168.56.0/24via10.1.2.11devtunIO 192.168.20.21devcalib10557e961d calib10557e951d calib0d7763386da src:192.168.20.21 dst:192.168.56.193 Routingtable: 192.168.20.0/24via10.1.2.10devtunIO 192.168.56.93devcali0d7763386da eth0:10.1.2.10 tunI0:192.168.20.0 eth0:10.1.2.11 IPIPtunnel:src:10.1.2.10 dst:10.1.2.11 tunI0:192.168.56.33 上图所示为数据包在不同节点的Pod之间遍历的方式。示例中使用的是CalicoCNI网络插件。每个网络插件对于PodIP地址(IPAM)的分配、iptables规则和跨节点网络连接的配置方式、以及节点之间的路由信息交换方式都有不同的策略。 1.当CNI网络插件收到来自Kubernetes的容器部署通知时，它负责指派IP地址，并在节点上配置相应的iptables和路由规则。 2.Pod1会使用Pod2的IP或Pod2的服务IP作为目标位置向Pod2发送一个数据包。 （图中使用的是Pod2的IP。） 3.如果使用服务IP，则kube-proxy会执行负载均衡和DNAT，并将目标IP转换为远程Pod的IP。 4.节点上的路由表决定了数据包的路由位置。 A.如果目标位置是相同节点上的本地Pod，则数据包将直接被转发至Pod的接口。 B.否则数据包会被转发至相应的接口，至于是哪一个接口，则取决于网络插件是使用 Overlay网络还是三层网络路由机制。 C.在上图中，数据包被发送至IPIP隧道接口，并通过IPIP隧道标头进行了封装。 5.当数据包到达目标节点，封装就将被移除。 6.远程节点上的路由表会将数据包路由至目标位置Pod2。 在路由、NAT（可能进行）和封装发生，并被网络插件管理，检查和监控网络流量中的攻击和违规连接都极其困难。 Kubernetes漏洞和攻击载体 针对Pod上运行的Kubernetes容器发起的攻击可能来自外部网络，也可能来自内部人员，包括那些系统被迫充当了钓鱼攻击通道的受害者。下面请看几个示例： 1.容器入侵：攻击者可能通过应用程序配置错误或漏洞进入容器内部，进而开始探测网络、进程控制或文件系统中的漏洞。 1 3 pod 4 east-west 25 6 HOST 2.Pod之间未经授权的连接：被入侵的容器可能尝试连接同一主机或其他主机上正在运行的其他Pod，以进行探测或发起攻击。尽管三层网络控制可通过建立IP地址白名单提供一定的保护，但通过受信任的IP地址发起的攻击只有通过七层网络筛选才能被发现。 3.POD数据外泄：攻击者往往通过多种手段实现数据窃取，其中可能包括在连接至命令与控制服务器的Pod上设置反向shell，以及通过网络隧道来隐藏保密数据。 4.通过被入侵的容器运行恶意进程：容器运行的进程通常比较有限，并且具有明确的定义，但被入侵的容器可能会启动挖矿软件等恶意进程，或网络端口扫描等 可疑进程，或者注入未曾出现过的二进制代码（进程攻击）。 WORKERNODES 5.入侵容器文件系统：攻击者可能通过安装存在漏洞的库/数据包来攻击容器，也可能修改敏感文件。攻击完成之后，可能会尝试权限升级或其他突破方式。 6.入侵工作节点：与任何活动的容器一样，主机本身也可能被攻击。例如，用户可通过 DirtyCowLinux内核漏洞升级至root权限。 攻击杀伤链 最具破坏力的攻击发生在杀伤链中，即通过一系列恶意活动来实现攻击者的目的。这些活动可能在片刻之内发生，也可能在几秒、几天、几周甚至几个月内完成。 准备攻击手段攻击命令与控制 杀伤链会利用不同的资源发起攻击，侦查实施 所以检测其中包含的活动需要多层安 安装外泄
