为什么Kubernetes安全这么难？

 kelvinji2009 译 分布式实验室 

如果你已经很熟悉Kubernetes，标题中的问题可能会让你产生深刻的共鸣。 如果你刚刚开始你的云原生之旅，并且Kubernetes就像一座若隐若现的等待你去征服的山峰，你很快就会意识到这个问题的针对性。
安全性在绝大多数时候都很难，但是当你的软件由大量运行在容器中的小型，动态，可扩展，分布式微服务组成时，它就会变得更加困难。 而且不仅是短暂性增加了困难，而且还采用了新的工作流程和工具链，所有这些都带来了新的安全考虑因素。
让我们深入挖掘一下。

技能

首先，Kubernetes和其他一些用于容器化微服务交付管道的工具很复杂。 它们具有陡峭的学习曲线，受到更改频繁和发布周期短的影响，需要付出相当大的努力才能掌握平台安全性的所有细微差别。 如果负责安全的团队成员不了解平台应该如何保护，或者更糟糕的是，没有人被赋予责任，那么可以想象平台中可能存在明显的安全漏洞。 即使在最好的情况下，这也可能会令人尴尬，而且最糟糕的是，这可能会产生有害的后果。
专注

为了在所选择的市场中成为创新者，或者为了应对外部市场力量（例如，客户需求或竞争对手活动）而变得更加敏捷，不管是新的还是老的组织，或者小型的和大型的组织都正在忙于采用DevOps。 重点在于新功能和修复的交付速度，以及开发和运营之间传统界限的模糊。 我们在开发和定义集成，测试和交付管道时考虑操作方面是非常好的，但安全性又如何呢？ 安全不应该是事后的想法。它需要成为软件开发生命周期中不可或缺的一部分，在流程的每一步都要考虑。 可悲的是，情况往往并非如此，但人们越来越认识到需要保证“向左移（shift left）”，并在交付渠道中得到适应。 这就是DevSecOps或持续安全（continuous security）。
复杂性

我们已经提到Kubernetes及其共生工具这一事实本质上是复杂的，而且有点难以掌握。 但它可以变得更糟，因为Kubernetes堆栈中有多个层，每个层都有自己的安全考虑因素。 仅仅锁定一层，而忽略组成堆栈的其他层是不够的。 这有点像锁了门，同时让窗户敞开着。
由于必须考虑并实现多层安全性，这会带来更多复杂性。 但它也有一个有益的副作用；它提供了“纵深防御（defence in depth）”，这样如果一个安全机制被潜在的攻击者规避，同一层或另一层中的另一个机制可以干预并使攻击无效。

所有层都要保持安全

那么，需要在Kubernetes平台中保护哪些层？
首先，有一个基础设施层，它包括机器和它们之间的网络连接。这些机器可能包含物理或抽象的硬件组件，运行着操作系统和（通常）Docker引擎。
其次，还有一个由Kubernetes集群组件组成的基础设施层：主节点上运行的控制平面组件，以及与工作节点上运行的容器工作负载交互的组件。
下一层涉及将各种安全控制应用于Kubernetes，以控制对集群的访问，定义运行容器工作负载的策略以及提供工作负载隔离。
最后，工作负载安全层自己处理容器工作负载的安全性、来源和完整性。此安全层不仅应该处理有助于管理工作负载安全性的工具，还应该解决这些工具如何合并到端到端工作流中的问题。

一些常见的主题

知道有一些常见的贯穿需要我们考虑的大多数层安全主题是很有用的。提前认识它们并在其应用程序中采用一致的方法可以大大有助于实施安全策略。

• 最小特权原则 - 在广泛的IT安全性中普遍应用的原则，其关注点是限制访问用户和应用服务必须具有可用资源，使得所提供的访问仅足以执行所分配的功能。这有助于防止权限升级;例如，如果容器工作负载受到威胁，并且它已经部署了足够的权限来执行其任务，则泄露的影响仅限于分配给工作负载的权限。

• 软件更新 - 保持软件最新是平台安全的关键。不言而喻，意思就是应尽快应用与安全相关的补丁，并且在应用于生产服务之前，在测试环境中就彻底运行相关组件。在部署全新的主要版本（例如2.0）时需要注意一些事项，并且作为一般规则，将alpha，beta或rc版本部署到生产环境中并不明智。有趣的是，对于与Kubernetes对象关联的API版本，这条规则不一定适用。例如，自Kubernetes v1.1以来，常用的Ingress对象的API版本为v1beta1。

• 日志和审计 - 能够检查以查看特定操作或操作链的内容或者是谁，对于维护平台的安全性非常有价值。应在平台堆栈的所有层中配置审计事件的日志记录，包括使用审计策略审计Kubernetes集群活动。应使用日志摄取工具（如Fluentd或Filebeat）收集审计日志并将其发送到中央存储库，然后可以使用Elasticsearch等工具或公共云等效工具存储它们以供后续分析。

• 安全与生产力的权衡 - 在某些情况下，安全可能被视为生产力的障碍。特别是开发人员的生产力与允许执行特权容器相关的风险（例如，在专用于开发活动的集群中），如果它允许开发团队以更快的速度前进，则可能是一个令人满意的风险。安全性和生产力（以及其他因素）之间的权衡取决于开发环境，生产环境，甚至用于学习和尝试的环境。在一个环境中不可接受的东西在另一个环境中是完全可以接受的。然而，不应简单地忽视与放松安全限制相关的风险。而应该仔细权衡，并尽可能减少风险。例如，可以使用Kubernetes本机安全控件（例如RBAC和Pod安全策略）来缓解特权容器的使用。

系列文章大纲

在Kubernetes平台上配置安全性很困难，但并非不可能！ 这是一篇题为“为云原生应用程序保护Kubernetes”的系列文章中的介绍性文章，旨在揭开Kubernetes平台的安全性方面。 我们无法涵盖每个主题和每个方面，但我们的目标是提供每个层的安全要求的良好概述，以及我们为客户运行生产级Kubernetes集群的经验的一些见解。
该系列文章包括以下内容：

• 为什么Kubernetes安全这么难？ (本篇文章)

• Kubernetes基础设施的安全

• Kubernetes集群组件的安全配置

• Kubernetes集群安全控制的最佳实践

• 管理Kubernetes容器工作负载的安全

原文链接：https://blog.giantswarm.io/why-is-securing-kubernetes-so-difficult/