Kubernetes是现在最流行的容器编排平台。世界上的Mesose和DockerSwarm几乎都消失了，老实说，我不会想念它们。但其市场主导地位的不利之处在于，Kubernetes也已成为想要破坏其安全性的不良行为者的严重目标。一些可悲的事实：容器安全状况不佳，目前56%的开发人员甚至没有扫描他们的容器！Gartner预测，到2023年，超过70%的公司将运行容器化应用程序。根据RedHat2022年的一份报告，配置错误占所有Kubernetes安全事件的59%。作为一个社区，我们需要为此做点什么！2022NSA/CISAKubernetesHardeningGuidelinesSummary最初于2021年8月3日发布，然后由NSA和CISA于2022年3月15日更新技术报告“KubernetesHardeningGuidelines”在这里提供帮助！对于依赖Kubernetes作为容器平台的组织来说，这是一份优秀的文档。它提供了有关如何保护平台安全的详细信息和实践示例。在这里，我将总结技术报告的主要内容，并根据我在云安全方面的个人经验提供更多见解。扫描容器和pod中的漏洞或错误配置我们之所以喜欢容器是因为镜像是一个不可变的软件包及其所有依赖项。不变性是一种资产，因为同一个容器可以经过质量保证过程，并从开发升级到生产而无需任何更改。但这也是一种负担，因为容器镜像是软件时间胶囊：它们不会在发现新漏洞时自动获取更新。扫描容器镜像以查找已知漏洞是一种安全最佳实践（尽管只有44%的开发人员这样做）。但大多数只是在最初将图像推送到注册表时扫描图像。这就产生了一个问题。因为应用程序越稳定，它更新的频率就越低，因此不能经常推送到注册中心。具有讽刺意味的是，稳定性使容器镜像更容易在更新之间变得脆弱。作为缓解措施，NSA/CISA报告建议使用Kubernetes准入控制器，该控制器将在pod部署时请求扫描。但如果你仔细想想，这会遇到同样的问题：如果你长时间部署一个不经常更新的应用程序，那么这种额外的部署时检查将无法正确保护长时间运行的应用程序。这就是为什么我强烈建议建立一个流程来定期确定将哪些容器部署到您的集群，并定期扫描这些镜像。只需安排每天的pod周期，并让注册表扫描它们以查找容器映像。这样，您的扫描结果是最新且准确的。以尽可能低的权限运行容器和Pod从第一天开始，Kubernetes和容器运行时的默认安全状态就非常松懈。在一个2/3的内部威胁是由于疏忽造成的世界中，给予软件或用户过于广泛的权限就是疏忽！容器中的默认用户是sysadminroot用户。您必须手动选择退出。Kubernetes对容器化应用程序的功能施加了一些额外的限制。因此，如果针对Kubernetes容器平台中的应用程序的网络攻击成功，则授予参与者的权限和权限集非常广泛。为了降低风险，应该制定策略来确保和执行：容器不以“root”身份运行（如果可能，容器运行时本身——默认用户运行），以限制应用程序的权限，从而限制黑客攻击行为；容器文件系统是不可变的，以防止不良行为者擦除他们的攻击轨迹；最严格的Pod安全策略(Kubernetesv1.21+)或Pod安全标准(Kubernetesv1.22+)用于，例如，以非root用户身份运行，并禁止特权升级本质上成为root，以及访问到容器主机操作系统；默认服务帐户令牌不需要访问pod，因为它们可能比您预期的更容易访问更多用于访问Kubernetes集群的API。您的应用程序可能甚至不需要它，那么为什么它默认存在？我认为不用说，这些基准政策应该始终到位。但你也可能有更多的政策。这些对您的组织来说很特别。为此，我衷心推荐使用Kubernetes中可用的配置以及开放策略代理(OPA)。它使用受官方库或第三方策略启发的配置，在每个请求的基础上强制执行所有策略问题。使用网络分离来控制妥协可以造成的损害程度。Kubernetes中的默认网络设置允许pod自由地相互连接，而不管它们部署在哪个命名空间中。这种免费的网络方法意味着坏人只需要进入一个pod就可以不受限制地访问其他pod。因此，整个平台的安全程度取决于您最不安全的组件，而坏人所要做的就是通过您最不安全的组件进入。然后，剩下的就是历史了。Kubernetes网络策略对网络施加可配置的限制。这些实现因所使用的容器网络接口(CNI)提供程序而异，但本质上成为Kubernetes资源感知防火墙规则。这使得指定只有“后端组件”应该调用“数据库”而不是其他任何东西变得容易。因此，API网关的弱点并不意味着平台中的任何组件都可以被轻易攻击。使用防火墙限制不必要的网络连接和加密以保护机密性Kubernetes容器平台由一个控制平面和一组??工作节点组成。控制平面节点托管控制整个集群的组件。因此，设法获得控制平面控制权的不良行为者可以进行任意后续攻击并完全命令集群作弊。通过防火墙的网络边界防御可以帮助减轻来自（外部）恶意威胁行为者的此类攻击。控制平面的任何组件（KubernetesAPI、etcd、控制器管理器等）都不应公开超过满足组织需求的绝对必要。另请注意，Kubernetes集群内的网络流量通常未加密。这意味着敏感信息可以被犯罪分子设法放置在容器平台中的软件获取和利用。为了防止此类攻击，可以对集群中的所有流量进行加密。如果集群使用提供加密作为配置选项的CNI提供程序，那么这是一个相当微不足道且完全透明的更改。例如，Calico可以利用WireGuard来做到这一点。如果您不能充分信任底层网络来满足您的信息安全需求，则建议这样做。使用强身份验证和授权来限制用户和管理员访问并限制攻击面Kubernetes容器平台在其API服务器中具有基于角色的访问控制。但是，出于某种原因，这些必须明确激活。此外，典型的Kubernetes安装会向安装集群的任何人提供一个永不过期的系统管理员“令牌”。使用此令牌可提供对集群的完全和永久访问。猜猜我对此有何感想？虽然默认情况下未启用，但Kubernetes支持通过各种方法进行身份验证。有多种，但我强烈建议使用OpenIDConnect令牌。您可以与许多身份提供者服务集成，并且大多数都支持颁发此类令牌。它们还可以包含有关用户所属组的信息，因此可以在组级别设置基于角色的访问控制规则。对于那些不这样做的人，Keycloak或DexIdP可能能够与它们集成。希望（并且慷慨地）被视为易用性的错误尝试，Kubernetes默认也支持匿名请求。毫无疑问，应该将其关闭。应启用并配置基于角色的访问控制以遵守最小权限原则。因此，只应向软件和用户授予最低限度的权限集，并且应根据要求审查任何额外权限的请求。如您所知，我建议(a)禁用管理员令牌，(b)启用OpenIDConnect，(b)禁用匿名访问，以及(d)启用基于角色的访问控制。并且，（e）您实际上尽可能地限制了权限。打开日志审计，以便管理员可以监控活动并对潜在的恶意活动发出警报Kubernetes控制平面具有内置的审计日志记录。但是，再次强调（注意这里的主题？），它们必须通过配置显式启用。就像KubernetesHardeningGuidance技术报告一样，我当然建议启用这些，以便运维人员可以深入了解集群中发生的事情。然而，简单地启用一个非常频繁的日志流（所有对KubernetesAPI的自动请求也会留下审计线索）只是大海捞针。大海捞针需要实际解析和使用这些日志。这可以通过在您的日志存储解决方案（例如Opensearch、Splunk或DataDog）中过滤表达式，或通过自动化系统（例如CNCF项目Falco）的自动和策略感知解析来完成。它可以结合日志处理服务充当自动化安全事件和事件管理(SIEM)系统。定期检查所有Kubernetes设置并使用漏洞扫描以确保正确考虑风险并应用安全补丁Kubernetes每年大约发布3次容器平台的新版本。仅针对当前版本和前两个版本提供安全更新。因此，为了保持最新的安全性，运营商必须至少每年安装一次新版本。最好他们会跟进每个新版本，因为我亲切地称之为过去非常幼稚的安全功能正在逐渐改进。我希望我现在已经说清楚了：默认情况下，Kubernetes并不安全。禁用的安全功能的数量表明默认情况下有意不考虑安全性。新的安全威胁不断涌现。因此，强烈建议对整个平台（包括控制平面和工作节点本身）进行自动漏洞扫描。如果发现问题，请立即报警。但是，有一个问题。自动化测试能捕捉到一切吗？不，绝对不是。但它确实捕获了一些更明显的错误，如果这些错误被不良行为者捕获，则表明该平台也可能在其他方面存在错误配置。以我的经验，即使不关心唾手可得的果实也是一个巨大的“欢迎”信号。自动化漏洞工具是否足够？许多工具承诺会自动扫描容器镜像中的漏洞以及Kubernetes集群的配置或其中管理的资源。这些提供了一个有吸引力的产品，因为它们会突出错误配置。但是它们在范围和功能上是有限的。它们没有（技术上也不能）涵盖NSA/CISAKubernetes强化指南推荐的所有内容。安全公司ARMO发布了Kubescape。它声称是第一个根据NSA/CISA技术报告中的最佳实践验证集群的工具。事实上，在撰写本文时，它确实包含一组不错的自动化测试。它使用KubernetesAPI，现在，截至2022年，它还使用主机级检查功能来执行检查。这使它能够访问大量可以检查的配置。但也有局限性：一般无法验证，比如容器注册中心的容器镜像漏洞扫描策略是否生效，审计日志是否自动审计，节点间是否有防火墙，是否有是您组织中最严格的权限限制。在虚拟机或云级别就位。所有这些都需要对组织政策和流程有更深入的了解，而不是期望工具拥有它是合理的。自Kubescape诞生以来，2022年的最新更新大大扩展了Kubescape的范围，例如拥有自己的图像扫描功能、RBACvisualizer和investigator、辅助修复等。它还与谷歌云集成，因此可以从那里收集信息。鉴于ARMO在2022年4月成功完成了3000万美元的A轮融资，Kubescape可以做的事情的广度和深度似乎只会显着增加。AquaSecurity还发布了kube-bench。它可以通过检查控制平面主机上运行的进程来检查控制平面的配置方式。不幸的是，它无法检查不属于Kubernetes配置的安全功能。所以答案是“不”。不能仅仅运行自动检查并声称拥有完美（甚至良好）的安全态势。还需要对安全策略有实际的了解，不仅是集群本身，还有更广阔的视野。超越NSA/CISAKubernetes强化指南以防止错误配置，不要只是检查它基于角色的访问控制(RBAC)可以确定谁可以在什么情况下做什么。但是仅仅因为一条规则说Lars可以在“生产环境”中“更新配置”并不意味着他可以无限制地访问——还必须防止Lars犯错。毕竟，三分之二的内部威胁是由于疏忽造成的。与大多数云系统一样，Kubernetes仅附带一个执行RBAC的系统，但没有合理的策略来强制限制用户实际可以做什么。事后检查错误配置是一些系统提供的功能；AWSConfig现在看到了为此目的的一些牵引力。但我更希望有一个完全防止错误配置的系统。策略应以自动执行的形式进行编码。CNCF项目OpenPolicyAgent(OPA)可以做到这一点。它可以充当Kubernetes准入控制器，因此可以确保不违反政策。OPA用途广泛；您可以从官方库中学习，也可以从其他现成的策略中选择并作为基础。授予该应用程序的任何权限也会授予不良行为者如果不良行为者设法破坏您的应用程序，他们将拥有与该应用程序完全相同的权限。也许这看起来很明显。但我的经验告诉我，这在实践中并没有受到重视。坏人将拥有Kubernetes容器平台、网络、云、第三方SaaS集成、VPN连接的后台位置——一切。毕竟，勒索软件之类的坏东西就是这样传播的。它们只会感染Web应用程序中的一个点，然后继续传播。链条的强度实际上取决于其最薄弱的环节。如果我们真的考虑一下，除了处理请求和发回响应之外，您的RESTAPI组件应该没有任何权限。牢记云资源我们都看到了头条新闻。无论是错误配置为允许匿名访问的S3存储桶，还是允许访问任何客户数据库的MicrosoftAzureCosmosDB主密钥，信息都很明确。每当我们使用云资源时，我们必须始终牢记它们及其配置。Kubernetes生态中有各种控制器，让云集成变得简单，简单就是伟大！但绝不允许简单性损害安全性。因此，您必须确保这些控制器不会对它们管理的资源进行幼稚的安全设置。您应该完全拒绝那些没有明确宣传其如何管理安全性的工具。这包括没有指定他们需要哪些IAM权限的工具，以及没有公开配置他们将强制执行哪些权限的方法的工具。您的应用程序是否无意中拥有云中的权限？您是否授予云服务器访问权限以修改您的云资源？AWS所谓的实例配置文件（其他云提供商在不同名称下有相同的概念）授予虚拟机修改云资源的权限。通过在该虚拟机内部运行，容器化应用程序也可以拥有它。它需要做的就是对云的元数据服务进行一系列网络调用，并且它具有您授予服务器的相同级别的访问权限。因为它在服务器上运行，所以云将其视为“服务器”。我一遍又一遍地看到人们会在这里和那里向服务器的实例配置文件添加一些权限，以使他们想做的任何事情都起作用。创建负载均衡器，更新一些DNS记录，修改自动缩放组；像这样的东西。但他们这样做只是为了支持他们的预期用例，而没有意识到所有非预期用例都将具有相同的权限。定期扫描所有已部署的容器镜像许多容器注册表支持在推送镜像时扫描它们。这很棒！NSA/CISAKubernetes强化指南建议准入控制器在部署时请求扫描。但是，如果由于软件稳定而将映像保持部署数周或数月怎么办？几周前的初始扫描可能是干净的，但今天的新扫描将揭示漏洞。相反，我强烈支持定期扫描所有主动部署到Kubernetes容器平台的容器镜像。通过识别所有已部署的容器镜像版本并每天扫描它们来自动执行此检查。这意味着您可以利用最新的漏洞数据库来对抗不经常更新的稳定软件的旧容器映像。如果扫描发现依赖项存在问题，您可以使用更新后的依赖项重建映像并在（希望）很少或没有其他更改的情况下部署它，因为代码本身没有更改。定期对整个系统进行安全测试您的软件工程师拥有外部威胁所没有的东西：访问源代码。如果您也给他们时间和祝福来对您的系统进行安全测试，那么奇迹就会发生。在过去的一个项目中，我深切地记得发现以自动化方式创建某种类型的资源会使整个系统突然停止。笔记本电脑可以成功地对整个系统发起拒绝服务攻击，而无需执行任何明显的恶意操作。即使您的工程师自己可能没有接受过安全培训，但主要思想是灌输安全第一的心态。这可能是一帆风顺和安全灾难之间的区别。制定灾难恢复(DR)计划和实践令人震惊的是，与我交谈过的许多公司都认为DR仅意味着“备份”。提示：真的不是。备份是必要的，但还不够。从灾难中恢复意味着能够在特定时间范围内在其他地方站起来整个技术堆栈。虽然灾难通常被认为意味着整个云区域的中断，但我认为安全事件绝对算作灾难！由于您不再信任已部署的应用程序，因此您需要回答以下问题：您可以多快关闭整个基础架构并将其恢复到事件发生前的状态？当被问及这个令人不安的问题时，仍然认为DR等同于“备份”的公司通常承认他们甚至没有尝试定期从这些备份中恢复。如果信息技术是您工作的核心，请认真对待这一方面。UsingIntrusionDetectionSystems(IDS)andSecurityInformationandEventManagement(SIEM)SystemsKubernetesHardeningGuidance提到了这些，但并没有真正告诉你如何处理它们或如何使用它们。IDS记录和监视应用程序的正常行为，并根据这些基线不断检查活动。如果应用程序开始以新的方式运行，则可能表明它已被不良行为者利用。例如，如果它开始尝试读取或写入通常不会读取或写入的文件，这是一个很好的迹象-它不像它自己开始那样做！CNCF项目Falco也可以帮助您遵循本指南。指定规则当然很麻烦，但提供您的应用程序所需的护栏是必不可少的。您可以从社区提供的服务入手。Falco可以结合使用，例如Elasticsearch检查您的（审计）日志并以这种方式充当SIEM。我也建议以这种方式使用它。如果您已经有不同的系统，请务必使用它。但是使用一些东西。由于当今的许多法规要求您通知用户有关数据泄露的信息，因此您确实需要一个有助于管理安全信息和事件的系统。安全日志数据量太大，无法手动处理，尤其是当您当前正受到攻击时。信息安全不是一次性的，而是一个持续的过程。威胁在不断演变，应对措施也必须如此。通过在我们的平台上设置防护栏并不断努力为我们的应用程序和服务器提供最少的权限，我们可以减少攻击面。云的内在复杂性和动态特性为不良行为者提供了许多攻击和隐藏的地方。我们有责任限制这些机会。结束语Kubernetes默认情况下并不安全，它本身也不安全。您绝对可以而且必须加强其配置。云供应商提供的所谓“托管Kubernetes服务”几乎无法为您提供本文中包含的建议。他们当然不会添加深度安全所需的任何其他工具。他们也没有兴趣这样做，根据他们的“责任共担模型”，他们负责云端的安全，而你负责云端的安全。
