影响混沌工程进入生产环境的两大阻碍，我们前篇已经详细分析了第一个阻碍“最小爆炸半径”，本篇我们详细分析下第二个阻碍“故障工具的安全问题”。
故障工具：混沌工程的核心之一是故障演练，而模拟故障的组件就是所谓的故障工具。目前国内最好的故障工具应该是阿里开源的ChaosBlade，它可以覆盖到系统和网络层面大部分的演练场景，而且对容器云也有很好的支持。更详细的ChaosBlade的介绍请参考这里https://github.com/chaosblade-io/chaosblade/blob/master/README_CN.md，我们这里主要把精力放在它的安全问题上。
安全隐患： 混沌工程的原则之一是趋于生产环境，最好直接使用生产环境，所以生产环境是包含了故障工具而且留有访问入口的。而因为故障工具其本身就可以造成线上故障，所以我们必须要对其访问进行严格的控制。以ChaosBlade为例，其访问方式有ssh命令和http两种，前者需要在运维体系中存在一个超级用户或者超级密钥对，它的泄露会对全网带来威胁；后者需要生产实例暴漏网络端口，也是个很大的隐患。
SSH命令和http两种方式二选一，哪种方式更安全？答案是后者。
前者会带来两大隐患，一个是登陆密钥对的管理，一个是被攻破后的危害。为了保证能进入生产任意一台机器，势必会有一个超级大key的存在，而对于它的维护和保管就成了很头疼的问题。当然你也可以每个业务甚至每台机器分配一个key，那key的个数上去后对于它们的管理维护成本也会骤升。再来看危害，密钥对丢失导致ssh进入生产机器，那后果是不可预估的，最坏的结果是全部生产机器都受影响，就这一点上也是我们坚决选择http方式进行交互的原因，因为http方式最坏的结果是能执行故障工具本身支持的这些命令，相对是可控的。
最理想的情况是我们在进行混沌实验的时候利用持续部署的自动化体系去在生产环境上部署混沌的环境，而只有混沌的算力才包含故障工具，这种混沌工程的构建相对比较安全，因为上述的隐患只存在于混沌机中，最坏的结果也就是混沌机被攻破导致混沌机故障，我们把它们销毁了就好。但是这样会带来另外一个问题，违背了Devops中“不可变基础设施”的思想，需要把混沌机镜像与生产机镜像区分管理，镜像上的不一样又让混沌工程偏离了“趋于生产环境”这一原则，失去了意义。
云实例具备一个cloud-init功能，它就是解决我们这一困境的钥匙！关于cloud-init的机制这里也不做详解，没有接触过的同学可以把它理解为云平台预留的启动后初始化的一种机制，你可以通过它执行脚本、设置hostname、与云平台交互等。通过cloud-init，就让我们用同一镜像在开机时判断到自己环境和场景的不同，从而进行细微的调整。
解决思路：
1、通过云实例的tag来区分是prod机器还是chaos机器。
2、cloud-init阶段根据tag来决定是否自动启动ChaosBlade的web功能，只有chaos才会启动。
3、异常发起的客户端地址尽量固定，这样可以通过安全组、防火墙等配置最大限度控制故障模拟请求来源。
4、需要进行混沌实验时直接利用生产镜像构建算力，直接对接生产流量。
1 运维只需要维护一个镜像，且符合不可变基础设施的思想。
2 混沌工具在chaos环境开机自启动并通过http方式调用，方便自动化。
3 随用随开，而且混沌环境很容易恢复，方便实现一键终止。
4 安全上最坏的结果，混沌机的ChaosBlade被非法调用，由于混沌机本身就有最小爆炸半径控制，而且随时可以销毁，所以影响面可控。
