877
DevOps实践 - 白名单二三事
为何加白名单是一件痛苦的事？
白名单的需求，即我们的部分应用，出于数据的敏感性与安全性，需要让指定的外包公司能访问，但其他外网用户不能访问的一种需求。
需求已明确，再看下我们之前的架构是否是天然支持这种需求。
一个域名接入阿里环境的应用，无非走VIP或者是统一接入层。
VIP：
内网给机器间调用，办公网给办公环境访问，互联网给所有外部用户访问，跨域给7网分离的网络间调用，可以看到VIP并不天然支持外包公司的精细接入需求。
统一接入层：
最早统一接入层只有主站集群，给所有外部用户访问，只是随着架构的演进才有了办公网的统一接入层，最近又有了以环境和BU为维度的统一接入层，早先的统一接入层也并不天然支持外包公司的精细接入需求。
为什么给外包公司加白名单那么痛苦，根源在于我们的架构天然就不支持这种模式，而任何的特例都要付出额外的代价，随着加白名单的需求越来越多，痛苦和风险就越大。
看一下痛苦在哪里，需求是外包公司员工提出的，接到这个需求的可能是CRM的运营同学，而运营同学直接找PE又说不清需求（搞不清楚要在哪个应用加白名单），运营同学就会先找开发转述这个需求，开发搞清楚需求后，再找PE实现这个需求，链路很长，中间可能会有信息的丢失，最后弄完了还得让外包员工测试，黄花菜都凉了。
早期有哪些白名单接入方式？
VPN方式：
- 背景：外包公司已经按照阿里IT要求，采购对应的VPN设备，并已经完成网络调试。
- 优点：接入后几乎不需要额外再做什么，外包公司凭借VPN设备访问内网应用，运营开发可能无感。
- 缺点：周期长，至少得一个月，因业务需求外包公司发现不能访问一般等不了这么长时间。
VIP方式:
- 背景：这种方式应用一般是个办公网环境的应用，办公网的vip，之前只能办公网环境访问，需要接外包环境就需要在vip上增加外包白名单，做一个加法。
- 优点：只需要针对vip。
- 缺点：网工需要介入增加vip白名单，vip过于分散。
ACL方式:
- 背景：这种方式应用一般是个互联网环境的应用，互联网的vip或者走主站集群统一接入层，若只有外包能访问，需要在应用的nginx层做一层白名单控制，白名单的ip可以访问，其他全部拒绝，做一个减法。
- 优点：只需要针对应用的nginx配置。
- 缺点：开发或者PE需要做应用变更，应用过于分散。
以上也可以参看米芾的文档：外包公司网络接入。
如何解决这个痛点？
从上述的接入方式看出，若要优化加白名单这个功能，只能从这三个方面去考虑了，VPN方式，对运营开发PE来说都挺好，但外包公司不接受，实时性不够，基本没太大优化空间，下面说说vip和acl这两种方式的优化。
ACL优化：
先来看看之前的变更模式，做ACL变更，白名单一般保存在单独的一个文件如CRM_IPs或者直接写在nginx-proxy.conf，我们需要批量把需要增加的IPs添加到nginx的allow配置项上，具体的可以看少谦的文档：关于nginx的访问限制(allow&deny)，操作可以看时序的文档：devops系列：如何给应用加nginx白名单（7层）。
如果是黑屏，需要改配置，然后推送所有机器，再更新基线；如果是白屏，需要变更配置，然后做一次发布，总体来讲模式有点重，消耗时间也不短。
优化思路，既然发布的模式有点重，那我们看看是否能去掉发布走推送模式，按应用维度把新增的白名单推送一次，如果能实现，可以把变更时间控制在几秒内，而开发也无需清楚到底要改什么文件，无脑推白名单就好。
再来看看如何实现，既然是推送，首先想到中间件的diamond有实时推送的功能，比如限流的配置，都是实时起效的，这块可以借鉴；其次推完了还得实时起效，白名单配置在nginx上，nginx本身不能动态识别，但是lua模块却可以。有了这两点，这个功能基本有戏。
以下是当时在做这个优化的时候记录的一些点供大家参考，虽然最终的优化方案并不是这个，但这个方案还是有值得借鉴的地方，没准下次优化会用到。
- 前端设计：这块比较简单，只需要一个应用的下拉框和白名单的数据框，白名单可能是单个的ip也可能是ip段，前端可以先检查ip或者ip段是否合理，实现增删改查。
- 后端设计：后端的逻辑并不多，如果前端没有做检验的工作，那这还块也需要放在后端功能实现，另外还需要对ip段做解析，因为lua模块还不支持ip段的解析，所以需要在服务端将ip段解析成ip再推送到应用。关于ip段的解析，如果是python，参考时序的文档：工程师奇技淫巧-IP段转换CIDR(python篇)；如果是java，可以考虑用这个包：org.apache.commons.net.util.SubnetUtils，增删改查时再考虑下重复ip的去重。
- diamond推送：这块遇到的问题，如果白名单数量较多，尤其是ip段解析后生成大量ip，这个ip会以url的参数形式进行传送，而这个段是有可能超过diamond能推送的范畴，印象中diamond最多推送是1M的数据，如果超过了会做截断，这块其实还需要优化。
- 应用端改造：改造包括去掉之前的白名单配置，增加lua配置，参考文档可以看这一篇（需翻墙访问）：nginx ip access limit with lua。有兴趣的还可以申请日常机器（10.125.30.123）的权限，所有的配置都在/home/admin/cai/conf里。其中diamond.conf配置了diamond_server和传入的ip如何对应到access_limit.lua，diamond推送数据的路径配置在/home/admin/cai/conf/diamond，/home/admin/cai/conf/diamond/snapshot/DEFAULT_GROUP/com.ali.white.ip是推送过来的白名单IPs。可能存在的问题是如果白名单数量多lua遍历白名单对nginx性能造成影响。对lua有兴趣的可以参考金九的这个文档：tengine+lua开发。
整体再说下这个功能：前端利用diamond推送白名单到应用的监听端，监听端配置了tengine的监听规则，tengine的lua模块实时遍历diamond推送过来的白名单IPs进行访问的过滤（只需推送配置，不需要重启服务），从而不需要进行发布就可以实现动态推送白名单功能。这个功能从前端到后端已完全实现，鉴于篇幅，代码就不展示了。这个功能简化了白名单的变更，只要有权限，不懂技术的也能操作，实时性也很好，但是还有一定的改造成本，尤其是lua的改造。
VIP优化：
再来看看vip优化，如果单纯还走vip，优化空间不大，只能是网工的工具改进，比如以前是手动添加，后续是自动化的任务添加，但是对于提工单的人来说还是比较痛苦。关键的问题在于每个应用有不同的vip，每个vip都有白名单配置，如果能把这些vip收敛掉，优化空间巨大。
替代方案：统一接入层。想一下我们的需求，办公网环境，而且外包公司可以访问，那这个统一接入层就需要是一个办公网的统一接入层，外加白名单需求让外包公司访问，而这个白名单IPs可以在办公网统一接入层的vip上收敛掉。
关于办公网统一接入层的概念和接入，请看青索的文档：办公网统一接入层接入规范。
关于在办公网统一接入层基础上增加白名单的，可以参考杨仪的文档：DevOps那些事儿——谈应用VIP架构的演进。
变更需求请参考：淘系应用通过接入统一接入层以支持https。
看下改造成本，一是去除应用端白名单配置，二是接入带白名单功能的统一接入层（crm.wagbridge.alibabacorp.com），新增白名单只需要针对同一个的vip做一次变更。
整体来看，这个优化方案是相对最优，尽管也有不完美的地方，如统一白名单之后，所有应用的白名单是一致的，精细化管控上并没有上个优化方案那么完美，不过瑕不掩瑜，整体看还是是最优的。
最后更新：2017-04-19 16:00:31