转载

避无可避：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单独重定向也可能很麻烦。