OpenIAM 简介

阅读数:83 2019 年 9 月 20 日 17:05

OpenIAM 简介

我们作为链家网的基础架构团队,提供了许多服务给业务线使用。在这个过程中,我们逐渐发现,(业务) 服务和 (基础) 服务之间,“资源隔离”是初期强需求,“权限管理”是远期强需求。

当前,我们有的系统通过客户端传递“用户名 / 密码”,隐式地将数据隔离在当前用户这个 namespace 下;有的系统使用 AppId 和 AppKey 的方式标明用户,在数据库中更为灵活地记录权限信息。

我们除了作为服务的提供方,还往往需要充当系统管理员的角色:我们通过代码 / 后台 / 数据库等方式配置管理权限。这类琐碎的需求隔三岔五出现,可能需要我们线下测试、线上修改,打断了原本的开发节奏;用户可能需要较长时间的等待,压低了预期。

随着提供服务的增多,每个系统都可能需要开发一套用户 / 资源 / 权限的子系统,这越来越成为一种负担,拖慢了上层业务的开发,且带来了不一致的用户体验。我们在思考,有没有一个通用服务,覆盖那部分通用性强的,业务无关的权限管理?它只需要很小的成本接入,就能够提供统一的身份识别和方便的权限管理。

实际上,SaaS 平台上早有了成熟的解决方案,它就是 Identity and Access Management 系统。在链家,我们同时使用了自建 IDC 和公有云服务 Amazon Web Service。我们期待自己的服务,也能集成类似 AWS IAM这样的系统。

介绍 AWS IAM

用户体系

在 AWS IAM 中,用户分为四类实体:

  • Account(Root User)

    • 帐号对拥有的资源,有所有权限

    • 帐号可分发权限给用户,或赋予用户权限代为管理

    • 资源隔离在帐户下,不可跨帐号使用

  • User

    • 帐号下的权限隔离

    • 推荐日常使用

  • Group

    • 用户可加入到用户组

    • 方便权限的聚合管理

  • Role

    • 方便第三方跨帐户使用

    • 用户可 AssumeRole 换取临时 AK/SK,切换到对应角色

其中,帐号和用户可以有访问凭证,分别是:

  • 用户名 / 密码,后台访问

  • AccessKeyId/SecrectAccessKey, 程序使用 HTTP API 访问

认证流程

对于用户请求的身份识别,通常有两种方案:

  1. 基于 Session,Session 过期后重新登录。
  2. 对每次请求加密,一次一密。
    AWS IAM 选用了方案二,后端无状态,请求更安全。

用户在程序请求时,使用申请好的 AccessKeyId 和 SecrectAccessKey,针对 Request 的当前时间,Header 字段, URL Query 参数,Body Digest 等元素,按照一定规则拼接字符串,生成签名。

Server 校验签名,确认当前用户,判断是否有对应权限,记录请求以供审计,完成请求返回结果。

策略文档

AWS IAM 使用了 JSON 文档的方式描述策略 Policy,并提供了策略编辑器工具帮助不熟悉的用户撰写文档。
我认为这是很棒的设计:

  • JSON 是程序员们广泛接受,能够手写的格式
  • JSON 支持 Array, Map 等复杂类型,方便聚合权限

官方示例 Policy 如下:

复制代码
{ "Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow",
"Action": [
"s3:ListAllMyBuckets",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::*"
},
{ "Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::BUCKET-NAME",
"Condition": {"StringLike": {"s3:prefix": [
"",
"home/",
"home/${aws:username}/"
]}}
},
{ "Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::BUCKET-NAME/home/${aws:username}",
"arn:aws:s3:::BUCKET-NAME/home/${aws:username}/*"
]
}
]
}

Policy 基于字符串的匹配,加上 Allow/Deny Effect 的组合,更通用、易理解的变量名称,和外部系统深度集成的 Condition 条件语句,灵活强大,自成体系。

最终,Policy 通过内嵌 (Inline Policy) 或附加 (Managed Policy) 的方式,挂接到帐户里的用户、用户组和 / 或角色,完成了权限的分发。

整个解决方案,用户使用简洁灵活,可以从策略文档,挂接方式,用户类型上管控;服务提供方只需要暴露出全局性的 Resource 和梳理提供的 Action 即可。用户通过一套机制,完成了对 AWS 所有服务的对接,在 IAM 后台完成了绝大部分权限管理的工作(比如,S3 除了支持 IAM 基于访问用户的权限,还提供了基于对象的管理)

自研

AWS IAM 是个私有服务,我们只能感知客户端 SDK 和后台 Console 的行为动作,S3/EC2 之类的服务和 IAM 之间交互是透明的,无法感知的。我们翻出了私有云的实现 - OpenStack KeyStone,看看是否不用重复造轮子。

在调研阶段,我们发现,KeyStone 只是一个 Identity 服务,只实现了身份的识别,权限信息仍保留在各自的 Service 上。并且,KeyStone 是基于 Role 的设计,即便是一个细微的权限问题,我们也要先建一个 Role 与之对应,然后绑定用户,异常笨重。由于从一开始就存在较大的阻抗匹配,我们放弃了基于 KeyStone 的二次开发方案,使用 Golang 从头开发了自己的实现:OpenIAM。

在决定自研后,我们投入了两个人力(其中一个是没有写过 Golang,帅帅的大三实习生,彬彬同学),在一个多月的时间内,完成了一期目标,完全兼容了 AWS CLI,用 Vue.js 复刻了 AWS 的 Admin Console。

我们除了提供 JSON/XML 的 HTTP 接口供用户日常管理之外,还提供了高性能的 gRPC 接口供服务提供方接入。

我们设定,服务提供方不应知道 SecrectAccessKey 和 Policy 信息。它接到业务请求,只需抽取 AccessKeyId、签名和签名所用字符串,申明签名方式 (如 HMac 哈希,Base64 摘要等),再加上服务自身感知到的 Resource 和 Action,一起交由 OpenIAM 完成认证和鉴权两步操作。我们使用这种方式,打通了业务 / 服务 /OpenIAM 三者之间的闭环。

整体的流程如下图:

OpenIAM 简介

OpenIAM 在授权认证时的简化活动图:

OpenIAM 简介

那么,在 OpenIAM 服务上线后,我们预期会带来哪些改变呢?

  • 服务提供方仅需告知 OpenIAM 创建资源的帐号;后期鉴权均由 OpenIAM 完成,对提供方透明。

  • 资源的拥有者,直接在 OpenIAM 上管理权限;服务提供方无权管理。

  • 客户端逐步统一访问方式,降低接入成本,一套 AccessKeyId/ScrectAccessKey 即可跨多服务使用。

  • OpenIAM 可整合接入服务的服务后台,提供一致的使用体验。

使用场景

我们可以看到,IAM 解决的是服务和服务间的身份认证 / 权限管理。

在 AWS 里面所有服务都是基础服务,均有较强的资源概念。在公司里,存在更多的业务系统,没有清晰的资源概念,OpenIAM 能够适配这种情况吗?

例如,一个 Restful 的 API 接口,提供了对业务实体的 CRUD 操作。我们可以将每一个业务实体当成一个资源,将 GET/POST/PUT/DELETE 映射成 Action;服务提供方在 Resource 定位符中,直接告知 OpenIAM 资源的拥有者,OpenIAM 即可在此帐号下完成对业务实体的权限认证。

问题二,服务有自己的用户权限体系,用户请求可能涉及到第三方服务的权限问题。用户权限跟 IAM 权限有什么关系,该如何划分边界?事实上,OpenIAM 不关注用户权限信息。业务系统可以有如下两种选择:

1. 一般情况下,业务系统的 AK/SK 拥有对第三方服务所需的所有权限,普通用户的权限由业务系统自行判定。

2. 业务系统可以预设几个 IAM 子用户,将应用级别的用户映射到不同的 IAM 用户,不同 IAM 用户拥护不同的第三方服务权限。用户请求时,将请求转用对应的 AK/SK 加密,由 OpenIAM 决策允许或拒绝。

总结

在微服务日益火爆的今天,服务的数量会积极膨胀。OpenIAM 希望能解决服务和服务间的资源隔离问题。我们期待能跟大家更深入地分享 OpenIAM 设计与实现,如果感兴趣请留言

本文转载自公众号贝壳产品技术(ID:gh_9afeb423f390)。

原文链接:

https://mp.weixin.qq.com/s/eY9HNeF4zroaOpU3oE8fKQ

评论

发布