刘陈泓：云服务中用户身份管理与访问控制的艺术

基于云计算的身份管理与访问控制无疑是考量云厂商的标尺之一。为了提高数据和应用程序的安全性，云厂商一般会采用多重身份验证。企业面临的挑战则是现有的身份管理与访问控制如果在不增加成本或成本很低的情况下扩展到云。二者之间究竟怎样平衡？随着云服务的不断发展，软件开发将有哪些变化？近期，我们采访了 UnitedStack 平台开发部开发工程师刘陈泓，听他来讲讲有云是怎么做的。

嘉宾简介：刘陈泓，现任 UnitedStack 平台开发部开发工程师，负责 UnitedStack 的身份认证、计费、面板等功能的开发，主要关注 OpenStack 的身份认证和计费领域。

InfoQ：目前，云计算行业通用的身份管理与认证方式有哪些？UnitedStack 在身份管理与认证方面有哪些特点？

刘陈泓：目前云计算行业还不存在标准的认证方案，不过倒是有些相似的方式。

• 从 Web 界面的角度来说，用户还是以传统的用户名 & 密码的方式来实现身份认证，这方面各平台都差不多。有些平台还会增加一些额外的安全验证，比如短信验证码之类的。总体来说，也算是业内的一些通用解决方式。
• 从 API 的角度来说，不同的平台还是有些区别的。有些平台采用了类似 AWS 的公私钥方案来验证发起 API 请求的用户身份的合法性；OpenStack 系则是采用 token 授权的方式，和 OAuth 的方案类似。另外，有些平台还支持使用外部身份源，这里的外部身份源一般就是 LDAP 服务，比如很典型的 Windows AD 域服务，AWS 和 OpenStack 都支持使用 LDAP 服务作为身份源。

UnitedStack 有云在身份管理和认证方面是基于 OpenStack Keystone 实现的，没有修改 Keystone 的身份管理和认证方案，这也是为了和社区的版本保持一致。但是根据业务需要引入了子账户和用户协作这两个功能，是在 OpenStack 基础上一种比较创新的应用。另外，UOS 还提供了运营平台，并且在运营平台内提供了细致的权限管理，允许用户为平台的不同角色的运营人员分配不同的权限，避免高权限操作和敏感信息的泄露。

InfoQ：你能点评一下 AWS IAM 吗？复杂的身份认证会降低效率、损害用户的体验，UOS 是如何平衡二者之间的关系？

刘陈泓：AWS IAM 是一套相当完善且高效的认证授权体系，其设计充分考虑了 AWS 用户的需求，尤其是企业用户的需求。现在有越来越多的初创企业户使用 AWS 作为自己的基础设施，也有一些传统的企业开始往 AWS 迁移一些业务。对于这些企业而言，使用 AWS 能够享受到云计算带来的种种好处，但是他们也需要考虑企业的信息安全问题，也就是传统上如何控制“哪些员工可以访问哪些资源或者数据”的问题。

AWS IAM 可以很好的解决企业的这些需求，企业用户不仅可以在自己的 AWS 账号内建立起一套完整的权限控制系统，而且也可以通过 AWS IAM 的 federation 功能和企业内部已有的身份认证系统结合起来。其次，除了可以建立或者引入账号身份体系，AWS IAM 还允许用户自己设置复杂的策略，比如“允许哪个用户在哪个资源上执行什么动作”。这种细粒度的策略给了企业相当大的灵活性。最后，还得提一下 AWS IAM 的方便性。IAM 所管理的账号不仅能够让用户通过 CLI 或者 API 来访问 AWS 的资源，甚至还能通过一个特定的入口 URL 来登录 AWS Management Console，通过 Web 界面来操作资源，非常方便。

UnitedStack 有云也意识到了这种账户和权限管理的重要性，所以有云 UOS 通过扩展的方式在 OpenStack 架构上实现了子账户管理和用户协作的功能。UOS 的子账户管理和用户协作的功能允许一个账号创建自己可以管控的子账户和项目，能够方便的在项目级别控制用户的权限，极大的方便了企业用户。

复杂的身份认证确实会降低效率、损害用户体验，现在所有的在线系统都在努力的找到安全和易用性之间的平衡。UOS 主要依赖于 OpenStack 的认证体系，这套体系在安全性和易用性上设计得还是取得了一个不错的平衡。不过，UOS 还是使用了一些常规的手段增强了安全性，比如使用 URL 代理、使用 HTTPS 来保护通信数据、使用验证码来防止暴力密码破解等。这些措施都可以在尽可能不影响用户体验的情况下，增加账号的安全性。

InfoQ：国内云厂商经常谈到“秒级响应”和“秒级计费”等。在您看来秒级计费的技术难点体现在哪里？

刘陈泓：秒级计费基本上是现在云服务商的标配了，按秒计费或者按使用量计费也是云服务能够吸引用户的一大特点。现在的云服务规模都在不断增大，而且都在一定程度上支持平台规模的弹性扩展，所以云平台会大量使用各种异步通信方式来确保用户的请求得到更快的响应。

比如你创建一个虚拟机，Nova 的 API 返回时只是告诉你这个请求被接受了，它还需要执行创建磁盘、创建虚拟机、连接虚拟机网卡等操作，完整这些操作一般需要 10 秒左右的时间，中间会涉及到多个服务的交互，而且是有可能出现失败的情况。在这种架构下，实现秒级计费的主要难点是准确性。一般来说，计费系统需要准确的知道用户创建资源的每个状态变化并且做出相应的计费操作。但是，在涉及到多个服务的交互时，资源状态变化的通知可能因为各种原因而没有被计费系统及时收到，这就会出现计费不准确的情况。服务规模越大，功能越多的平台，这种情况就越容易出现。随着云服务的发展，很多服务商开始提供多个区域的资源，比如 UOS 公有云平台提供了北京和广州两个区域。这种多区域的部署，也会给秒级计费的准确性带来一定的实现难度。

InfoQ：要实现这种资源的弹性配置，监控系统无疑十分重要。您能分享一下 UOS 监控系统的架构细节吗？

刘陈泓：UOS 的监控系统分为两个部分，一个部分是传统的监控，基于 Zabbix 实现，主要用来监控一个云平台的基本架构的稳定性，包括物理机或者虚拟机的性能数据、网络的连通性等。另外一部分，则是通过 API 来模拟用户的操作，以监控云服务业务的可用性。我重点介绍一下后面这部分的架构吧。

我们内部开发了一套测试监控系统，通过 API 来模拟用户的操作，像创建虚拟机、创建路由器、测试网络连通性等。这套监控系统是由测试用例组成的，它会针对我们的公有云和托管云定期运行测试用例，用来确保每个云服务的可用性，一旦发现服务异常就会发送告警给相关人员。同时，这套系统还针对云平台的弹性配置特性，允许测试新加入的计算节点和网络节点，确保平台的扩展不会带来新的问题。

InfoQ：想请您谈一下 UOS 对 DevOps 的支持情况？以及您怎么看待云服务上的软件开发趋势？

刘陈泓：我并不是 DevOps 专家，所以只能简单谈谈一点看法。首先，UniedStack 的组织架构有利于我们实现和改进 DevOps，开发、运维、运营等人员之间的交流十分直接和高效。其次，随着业务的发展，我们要部署越来越多的托管云、同时还要不断更新公有云的功能，为此，我们研发部门始终觉得自动化程度的高低决定了 DevOps 水平。所以，我们的各个服务都尽可能在测试和部署环节提高自动化水平，包括自动化测试、自动化部署、自动化更新数据等。尤其是我们的运维部门，他们还开发了一套一键部署系统，大大提升了我们的托管云部署效率。

随着云技术的发展，现在应用开发都开始依赖于云服务。一开始的时候，用户使用云服务器来替换物理服务器，这提升了灵活性和稳定性；后来，用户又开始使用云平台的各种集成服务，包括存储、安全、大数据分析等，这提升了开发效率；现在，AWS 还推出了 lambda 服务，就是要让用户忘掉虚拟机的存在，只需要考虑业务逻辑。所以，在我看来，云服务上的软件开发呈越来越方便的趋势，开发人员会慢慢转变开发习惯，会开始依赖于云平台的现有服务。另一方面，随着用户越来越依赖于云服务，他们会更多的使用云服务的各种接口（比如 Web 界面或者 API）来执行传统的运维工作。Web 界面是非自动化的，对于使用量大的用户来说，大量使用云服务的 API 也会成为一种趋势。

InfoQ：现在，越来越多的云厂商在开放 API、打包自己的 SDK，在给开发者带来便利的同时也带来了很多安全问题，比如最近百度 WormHole 后门事件。您认为云时代的软件工程应该怎么避免这个问题？

刘陈泓：现在的很多云厂商提供开放 API、SDK 的本意都是为了更好的帮助开发者提升开发效率，总的来说，很少有厂商故意植入后门。不过，防人之心不可无，有些防备措施总是好的。我觉得要避免这种问题，流程上可以做的事情更多。首先，要规范 SDK、IDE 的下载渠道，从非官方的渠道获取这些东西要冒极大的风险，XCode Ghost 的教训还历历在目。其次，如果有条件就尽量选择开源的 SDK 或者自己封装 SDK。测试方面，对 SDK 做安全分析并不是每个厂商都做得到，不过，一般后门程序都会通过网络收发数据，在测试过程中检查应用收发的数据是否规范是一个比较容易实施的方案。

InfoQ：最近刚刚在东京结束了 OpenStack 峰会，您能谈一些对前沿技术的看法吗？

刘陈泓：这次的 Summit 上容器技术和 magnum 项目无疑是最热的。过去这两年容器技术已经有了长足的发展，前几天 Docker 刚发布了 1.9 版本。我个人觉得容器的应用会越来越广泛，之前困扰容器的网络和存储问题会慢慢得到解决。OpenStack 也正在将容器的管理和应用纳入其体系之中，即 magnum 项目。不过，目前各个容器的管理和编排技术也在快速发展当中，magnum 项目也才刚起步，现在还无法看出 magnum 项目最终是否能成功。