避无可避： Mesos 安全问题的几点思考

小数今天为大家抱来的内容，是有关Mesos的一个安全问题。这个问题可以说是目前行业内容器管理工具的一个通病， Mesos 的团队已经在尝试解决它，那么在正式的解决方案出来前，我们也可以有办法来避免它——看看本文作者是如何思考的。

笔者研究 Mesos 已经很长时间了，在大多数情况下，享受着围绕 Mesos 整个生态系统的成长过程。为了应用（或者微服务）交付而在一个大平台上统一管理服务器是一件非常酷的事情。虽然有一些学习曲线，但是 Mesos 是一个非常好的应用配置工具，同时还可以把它看做统一架构进行规模扩展以及应用管理。

但是每一个技术都存在自己的缺陷和问题，我们必须诚实和开放地对待，才能让它更好地应用于企业生产。 Mesos 也不例外。

身份验证，开 or 关？

大多数开源项目都是这样开始的：“如果我们做到了 X,Y 和 Z ，那么我们就可以做到这件很酷的事情了！”然后只考虑目标用户的安全需求，这是它们的通病。 Mesos 团队已经踏上了从无（或者可选）到有的企业级安全之路，但是现阶段，现在仍有一些可以值得考虑的事情，让 Mesos 安装更加安全。

Mesos 之父 Ben Hindman 是这样说的，“对于没有身份验证的用户来说，我们不希望在升级的时候打破他们的集群。身份验证将在默认有足够时间的情况下让应用框架升级。当一些应用框架可以身份验证同时另外其他应用框架并不支持这种升级路径时，我们开启了一种混合模式来应对。”

现在 Mesos 的安装默认是没有应用框架的身份验证的，也没有限制可以看到哪些应用框架。如果你使用命令行开关，可以修改这个默认行为，但是涉及到的应用框架仍然是默认打开的。本篇文章的目的即在于督促大家尽可能地在环境中使用命令行开关。

而行业标准和 Mesos 的做法完全相反——提供一个关闭安全的选项——但是默认它是开启的。虽然这样会使最初的部署更加困难，但这恰恰是 Mesos 需要的（从 Ben 的评论中得出的推断，他们或许正打算这么做）。

Mesos 的核心安全问题

接下来的这些产生了核心的问题：

默认情况下， Mesos 允许没有身份验证。通常情况下，一些形式的身份验证是需要的。越来越多的 OAuth 访问控制被使用。参见 Stormpath 或者 DigitalOcean 诸如此类的 API 认证方案。
Mesos 使用“角色（ role ）”来决定哪一个应用框架访问资源。默认情况下，应用框架可以注册为任何角色。
持久化磁盘（例如数据库或者合同目录）可以由 Mesos 进行资源分配。访问被角色限定（历史版本中的最近点）控制，让它们可以用于多个应用框架上的多个应用。这也使得任意和可访问应用框架有相同角色的应用框架可以被访问。
Mesos 可以根据需要通过 mesos fetcher 给集群中的节点分配 agent 。所以 agent 的分配，将是这一弱点的限定因素，实际上相当简单——一个应用框架可以要求它的 agent 下载到集群中的任意一台服务器上。
公共应用框架开发框架。

所以 Mesos 的默认安装，任何机器都可以点击应用框架的 REST API ，我可以注册一个自己架构的应用框架。 Mesos 系统自动批准注册，所以没有人员参与决策；注册（也叫：调度器订阅）意味着没有授权也会批准，并且会回复注册信息。考虑添加应用框架的频率很低，这应该是一个有人员参与的决策处。注意，更早期的应用框架开发使用 libmesos 所以可能滥用这种默认，但是那样更加困难，因此不太可能被利用。新应用框架可以申请存在其他应用框架的角色，之后只需等待 Mesos 传递给我正确的资源，就可以访问这些静态资源。这些资源可能包含任何分配给这个角色的持久化存储磁盘，可以读写（因为目前 Mesos 只支持读写）。

再次强调，这是一个已知的问题， Mesos 团队正在解决它。但是现在，用户需要根据自己的环境来决定是否需要自己实现。

解决之道

解决方法也很简单，有命令行选项开启应用框架身份验证，限制哪一种应用框架使用哪一种角色。但是需要把它们都打开——它们默认都是关闭的——观察 Mesos 集群的日志，没有显示应用框架注册是默认登录设置来登录的。注意角色管理是额外的开销，但是适用于应用框架还不是一个大的安全负担，除非频繁不断地从系统里添加 /移除应用框架（非常不可能的情况）。系统目前如此设计的原因是一些应用框架并不支持身份验证，所以在生产环境之前将这项功能开启进行测试也是很有必要的。

这个问题的风险大吗？坦白地说，这取决于实现过程。如果 Mesos 问题集群把敏感信息放在持久化存储磁盘上，风险可能很高。如果问题集群没有这样做，仍然存在架构设计上的风险以及认证的缺失，但是可用数据—— Mesos 之外如何保护它——决定了它会受到何种攻击。修改运行应用的配置参数的能力是更深层的考虑； HTTP 单独重定向也可能很麻烦。

总结

简而言之，这个过渡期的存在，让我们更加意识到 Mesos 安全的重要性，因为一个未能共同遵守规范的实践，让项目的其他地方受到类似安全设计决策的影响，目前它已经在修复身份验证这个问题。

因为是过程中的不同阶段，所以实现几乎总是和调研时发掘出不同的信息或者问题。有时间多做几个应用框架后，会把信息升级，用一个“正常者”和一个“攻击者”进行测试。安全上来说，在有足够充分的文件说明的情况下，优先彻底检验问题是最好的，但我选择在准备好可能很长的证据之前先通知社区。

本文的意义在于帮助大家使用 Mesos 的时候绕掉那些已知的坑，建议大家使用“命令行”开关，阅读打开身份认证的指导，然后再实现它。并且建议限制角色，至少打开验证应用框架的开关并在环境中测试它是否工作。然后再畅游 Mesos 的世界，享受它带来的种种便利。

Note ：虽然开源技术都有这样那样的问题，但是作为出色的 Mesos 技术框架，那些在大规模生产集群下使用的知名企业众多，小数顺便再盘点下—— 国外有： Airbnb ， Apple ， Cisco ， eBay ， PayPal ， Time Warner Cable ， Twitter ， Uber ， Netflix ， Bloomberg ， Verizon …… 国内有：小米，新浪微博，爱奇艺，去哪儿网……

本文作者： DON MACVITTIE 原文链接： https://devops.com/mesos-security-awareness-considerations/