InfoQ|我们为什么不用Kubernetes?( 四 )


https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11246
CVE-2019–11253(7.5 高) :使授权用户可以发送恶意 YAML 或 JSON 载荷 , 导致 API 服务器占用过多的 CPU 或内存 , 可能会导致崩溃或服务不可用 。
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11253
概述
Kubernetes 是一个功能强大的 PaaS 工具包 , 具有许多安全相关的选项 , 可以支持各种部署场景 。 当它成为大家普遍认可的 PaaS 选项时 , 从安全的角度来看 , 这是非常有价值的 , 因为这些安全选项中的大多数都可以抽象出来 , 并且必须配备辅助系统以支持其使用 。
InfoQ|我们为什么不用Kubernetes?
本文插图

控制平面(AWS 账号 / GCP 项目)
Kubernetes 集群的操作是在提供给它们的服务和网络中进行的 , 自然地 , 就会与 AWS/GCP 控制平面进行一些交互 , 比如配置 Ingress 负载均衡器、访问存储在 KMS 中的秘密等 。 随着时间的推移 , 团队会发展壮大 , 拥有独立的帐户、项目并进一步的隔离 。 一个单独的 AWS 帐户或 GCP 项目是实现完全 IAM 分割(segmentation)的主要原语 。
另一方面 , Kubernetes 集群需要在一个 AWS 帐户内操作(即使与其他地方的集群联合) 。 这限制了分割选项和灵活性 。 我们可以为每个团队或服务提供一个集群 , 但我们就无法利用 Kubernetes 的许多好处了 , 并且会带来新的管理问题 , 比如对所有这些集群进行元编排 。
集群 & 节点 &Pod& 容器
集群
集群主(API)服务器是一个次控制平面(AWS 控制平面之外) , 我们也需要做好安全防护 。 服务帐户和访问范围(容器可以假定要访问集群内外的资源)与 AWS 的 IAM 一样复杂 , 并且需要严格地相互映射 , 以便中时断不会影响 AWS 控制平面 。
节点
底层节点的操作系统必须像我们现在所做的那样进行维护 。 事实上 , 我们的操作系统与谷歌用于 GKE 的基本操作系统非常相似 。 虽然将我们的操作系统转到 Kubernetes 不必做任何修改 , 但我们也不会得到任何东西 。
Pod
在集群中创建 Pod , 以及定义它们创建时必须满足哪些标准的规则 , 都是通过 PodSecurityPolicy 完成的 , 它的运作方式类似于 Salus 和我们现在使用的一致性管理工具 。 要实现干净利落的集成 , 我们将需要做大量的集成工作 , 并投资于附加的开源依赖项 。
https://github.com/coinbase/salus
Pod 通过网络策略相互隔离 , 就像我们现在使用安全组和 / 或内部服务框架所做的那样 。 但在 Kubernetes 领域 , Pod 相互通信所需的标识、身份验证和授权涉及大量的支持技术 , 如用于节点级以下标识格式和认证的 SPIFFE&SPIRE , 用于授权控制的 Envoy , Istio authN 和 Z 编排 , OPA 授权策略 。 对于其中的每一项技术 , 要将其标准化并应用到生产中都需要付出很大的努力 。
容器
容器不是安全边界 , 而是资源边界 。 为了定义容器的安全边界 , 需要深入研究自定义内核命名空间、系统调用过滤、强制访问控制框架和 / 或为容器设计的基于 VM 的隔离技术 , 如 gVisor 。
https://github.com/google/gvisor
目前 , 我们在这个领域的投入还不太多 , 因为我们还没有采用多租户的方式 。 如果我们转向多租户模型 , 我们将不得不立即进行大量的投资 , 通过主机 /VM 隔离技术保证类似分类的 Pod/ 容器在相同的节点上运行 , 不会相互干扰 。
8
我们何时会运行 Kubernetes?它在我们未来计划中吗?
当更高级的容器编配平台有重要的用例时 , 我们可能会首先查看问题声明 。 如果该平台很容易添加到我们现有的平台上:我们可能会首先访问它 , 然后从那里开始探索 / 了解 。 如果我们认为扩展 / 添加到我们的平台上不合理 , 那么我们将访问所有可能的选项——而不仅仅是 Kubernetes 。 更可能的情况是 , 我们会先了解 AWS 的托管服务 , 如 Fargate 和 ECS , 然后再了解 Kubernetes 。


推荐阅读