得益于 Kubernetes 面向终态的理念，云原生架构天然具备高度自动化的能力。然而，面向终态的自动化是一把“双刃剑”，它既为应用带来了声明式的部署能力，同时也潜在地会将一些误操作行为被终态化放大。因此，充分了解云原生环境下那些潜在的影响应用安全的问题，提前掌握多方位的安全防护、拦截、限流、熔断等技术手段来保障云原生应用的运行时稳定性至关重要。
本文整理自作者阿里云容器服务技术专家，OpenKruise 作者 & 初创人员之一，Kubernetes、OAM 社区贡献者王思宇(酒祝)于 1 月 19 日在阿里云开发者社区“周二开源日”的直播分享，介绍了云原生环境下应用安全与可用性的“处处危机”，分享阿里巴巴保障云原生应用运行时稳定性经验，并且详细解读了后续这些能力将如何通过 OpenKruise 赋能给开源。
云原生环境应用安全“危机”
1. 阿里巴巴云原生应用部署结构
这里的云原生应用部署结构是在阿里巴巴原生环境最简化的抽象图，如下图所示。
首先我们来看几个 CRD。CloneSet CRD 可以理解成 deployment 的一个 workload，也就是给应用部署 Pod 的模板。有了 CloneSet CRD 之后，不同的业务以及不同的应用会建立对应的 CloneSet，在 CloneSet 下面再建立对应的 Pod，以及对 Pod 做一些部署、发布相关的管理。
除了 CloneSet 之外，还提供了 SidecarSet CRD，这个 CRD 做的事情是在业务 Pod 创建阶段注入 SidecarSetCRD 中定义的 Sidecar 容器。也就是说，在 CloneSet 中业务只需要定义 Pod 中的 app 容器，也就是业务容器。在 Pod 创建过程中，通过 SidecarSet 在其中定义业务中要注入哪些 sidecar 容器。
2. OpenKruise：阿里巴巴应用部署基座
开源的 OpenKruise 是阿里巴巴应用部署的基座。OpenKruise 提供了多种的 workload。其中包括：CloneSet、Advanced StatefulSet、SidecarSet、Advanced DaemonSet。
CloneSet：是面向无状态应用部署的工具，也是阿里巴巴中使用规模最大的部分，绝大部分泛电商业务都是通过 CloneSet 来部署发布，包括 UC 神马、饿了么、电商业务等。
Advanced StatefulSet：针对一个原生 StatefulSet 兼容的增强版本，是面向有状态应用部署的工具，目前主要是用于中间件在云原生环境的部署。
SidecarSet：是在阿里巴巴环境中 sidecar 生命周期管理的工具。阿里巴巴的运维容器，以及阿里内部的 Mesh 容器，都是通过 SidecarSet 定义、部署以及注入到业务 Pod 中的。
Advanced DaemonSet：是针对原生 DaemonSet 兼容增强版本。将宿主机级别的守护进程部署到所有节点上，包括各种用于给业务容器配置网络、存储的基础组件。
介绍完基础环境之后，我们已经对云原生部署结构有了一个基本的了解。下面，我们来了解在云原生部署结构之下存在哪些云原生应用安全危机。
3. 云原生应用安全危机
1)workload 级联删除
Workload 级联删除，这一点不只针对于 Kruise 的 CloneSet，对于 Deployment，对于原生的 StatefulSet 都存在类似的问题。指的是当我们删除一个 Workload 之后，假设使用采用默认删除，没有使用 orphan 删除这种策略的话，底下的 Pod 都会被删掉，这里存在一种误删风险。也就是说，一旦某个 Deployment 被误删，那么它底下的所有 Pod 都会级联被删掉，导致整个应用不可用。如果有多个 Workload 被删掉，就可能导致很多个业务出现不可用的情况，这是一个对可用性造成的风险。如下图所示：
2)namespace 级联删除
那么我们再往上看，如果 Namespace 被删掉，那么整个 Namespace 底下的所有资源，包括 Deployment、CloneSet 这些 Workload，也包括 Pod、Service 等所有资源都会被删除，这是一种很高的误删风险。
3)CRD 级联删除
如果有用 Helm 部署的同学可能会遇到过类似的情况，也就是如果你的 Helm 中包含了一些 CRD，这些 CRD 都被定义在 template 中， 那么当 Helm uninstall 的时候，基本上这些 CRD 都会被 Helm 包级联删除掉，包括有人手动误删了某个 CRD，那么 CRD 底下对应的 CR 都会被清理。这是一个很高的风险。
如果 CRD 是 CloneSet 这种 Workload 级别的 CRD，那么一旦删除这个 CRD 之后，会导致所有 CRD 底下的 CloneSet 的 CR 对象全部被删掉，从而导致所有的业务 Pod 全部被删掉。也就是说，删除一个 Workload，只是这个 Workload 底下的 Pod 被删掉;删除一个 Namespace 可能只是 Namespace 底下的 Pod 被删掉。但如果像阿里巴巴这种场景下，如果有人把 CloneSet 或者一些很关键的 CRD 删掉的话 ，其实很可能导致整个集群环境所有 NameSpace 底下的 Pod 都会被级联删掉，或者说都会处于应用不可用的状态，造成云原生环境对于应用可用性的风险。如下图所示：