云计算新人之公有云 IAM

本篇文章简单的说下目前公有云厂商的 IAM 机制，以全球最大的三个云厂商为例（AWS，Azure 和 GCP），在说明的过程顺带浅谈一下它们家存储产品（也就是 S3，Azure Blob Storage，和 Google Cloud Storage），毕竟这玩意是我们和 IAM 打交道最多的产品。

IAM 的作用

IAM，Identity and Access Management，字如其名，就是用来负责鉴权的。鉴权最简单的方法是什么？不就是登入网站的账号和密码，也就是对应云厂商的 Access Key（AK） 和 Secret Key（SK）。然后你就会发现，一堆存储厂商凭借着 AK/SK 机制，能无缝支持 S3 协议，然后你可以拿着 AWS 的 S3 SDK 到处访问，除了微软。是的，微软不支持 AK/SK。

但是传统的 AK/SK 有着很明确的弊端，我简单的列下缺陷：

• 一旦 AK/SK 密钥泄露，你除了销毁 AK/SK，别无它法。不要以为这种事情不常发生，经常会有程序员把 AK/SK 写死在代码里面，然后发到 GitHub，CSDN 等博客上面，等着别人脱裤。
• 大多数云厂商的 AK/SK 做不到细粒度化的权限控制，基本上你拿到了 AK/SK，相当于你拥有了一个 root 账号。
• AK/SK 不利于开放权限给第三方，比如你想让第三方应用访问你的存储桶，如果你把 AK/SK 给了出去，就相当于人家拥有了你的 root 权限，危。
• 如果你是一个老板，手下的员工需要和存储桶打交道，你做不到即不让员工知道 AK/SK，但是又能让其有权限操作公司的存储桶。
• …

AK/SK 的问题太多了，实际上除了个人开发者图方便，没人愿意使用 AK/SK。而云厂商的 IAM 就是为了解决这一系列的问题。

一般 IAM 都是采用类似 RABC 的结构，有系统分三个类目，分别是 User，Role 和 Policy。一个 Role 可以包含多个 Policy，一个 User 只能有一个 Role。当然你也可以直接把若干的 Policy 直接附加到 User 上面。

下面我先分别阐述三个云厂商的 IAM，最后在结尾进行汇总对比。AWS 我会说的仔细点，其他厂商的就简单提一嘴，毕竟 IAM 这套逻辑其实都大同小异。

AWS

云计算的老大哥。AWS 的 IAM 中是不存在 Region 的概念，是 Global 的。而且在 AWS 中的所有资源，都有一个全局唯一标识符 ARN。比如 arn:aws:iam::081912308565:user/user_full_permission 这样。注意，这里 ARN 的全局，指的是在 AWS 下的唯一，而不是你当前账号下的唯一。

AWS 的 IAM 设计的中规中矩，很好懂。我们主要关注就是 Users，Roles 和 Policies。User groups 这里就不说了，是个人都知道。

一个 User 可以 attach 一个 Role，一个 Role 可以 attach 很多个 Policy。当然你也可以直接把多个 Policy 直接 attach 到 User 上面。

AK/SK

AWS 里面的 AK/SK 是和 User 绑定的，一组 AK/SK 代表一个 User。创建完一个 User 后，你可以在 Security credentials 菜单栏创建属于这个 User 的 AK/SK。

Instance Profile

有些时候，上级不想让码农知道 AK/SK 的实际内容，咋办？

AWS 提供了一种 instance profile 机制，老板可以把一个 Role 绑定到 EC2 上面，然后这个 EC2 访问任何 AWS 资源，都会自动携带上这个 Role 的信息去访问，这样相当于操作这个 EC2 的码农，其实并不知道任何 credential 信息。

Instance Profile 的原理其实很简单，就是 AWS 的 SDK 默认都会请求一个内网 IP http://169.254.169.254/latest/api/token，如果该 EC2 上绑定有 Role，这个 IP 就会返回一个 temp credential 给 SDK，然后 SDK 拿着这个 temp credential 去访问资源。

但是你创建的默认 Role，EC2 上是绑定不了的，需要设置 Role 的 Trusted entities 为 EC2，才可以绑定到 EC2 上面。

在创建 Role 的时候直接这么选，就相当于创建了一个可以用在 EC2 上面的 Role。

然后在 EC2 上面附加上就行了。在 EC2 控制面板上面，点击 Modify IAM role 就可以选择自己刚刚创建的 Role 了。

Assume Role

现在我们可以发现，其实 AK/SK 和 Instance Profile 均能代表一个用户，只不过 AK/SK 用的是 long-term credential，Instance profile 用的是 temp credential。但是考虑一种情况，如果此时我所代表的用户是一个没有任何权限的用户，而我需要去获得一个 s3 的读权限，怎么办？AWS 提供了一种 assume role 的机制，能允许我们基于一个用户的 credential，去取得另一个 Role 的权限。

我简单说下操作流程（过程其实没有那么死板，有很多种创建方法）：

1. 首先创建一个 policy，一个允许 assume role 的 policy。可以看到，我们可以设置该 policy 所能 assume role 的 arn。注意哦，arn 是全局唯一的，意味着你甚至可以 assume 其他 aws 账号下的 role。

2. 然后就是创建一个 user，attach 上刚刚创建的 policy。
3. 当然被 assume 的 role 也要配置一下信任策略，不然阿猫阿狗都能够 assume 它。和前面配置 Instance profile 一样，你需要在被 assume role 上的 trust relationships 里面进行配置。此外你可以额外配置一个 external id，你可以理解为一个密码，就是其他用户 assume 你这个 role 的时候，还需要附带一个额外的密码。

小结

AWS 就简单的说道这里吧，其实还有很多高级的用法没说到，比如用在 K8S 里面的 WebIdentity 等等。

Azure

Azure 是所有厂商里面最反人类的，产品设计的异常复杂难懂，而且非常喜欢造词，总是发明一些莫名奇妙的词语。

先要说一下 Azure 的整体架构，Azure 最上层是一个 Subscriptions，所有产品都一定隶属于某一个 subscription。然后一个 subscription 下面又有多个 resource group。Resource group 下面的才是对应我们真正的产品，比如 virtual machines 这些。

正因为这种继承的关系，使得权限也能被继承，上层 subscription 的权限，会默认覆盖其下层所有 resource 的权限。这也就是为什么你可以在 Azure 中的每一个资源左侧都可以看见一个 IAM 面板。上面记录着该资源绑定的权限， 以及这些权限的 scope（Inherited 表示是从上面继承下来的）。

Azure 的存储就非常奇葩了，它发明了一个叫 storage account 的玩意。一个 storage account 下面可以创建 4 种类型的存储，分别是 Containers，File Shares，Queues 和 Tables。其中 container 对应的就是我们常说的对象存储。一个 storage account 可以创建多个 container，每一个 container 是 storage account 下的一个目录。Container 对应的就是 AWS 里面 S3 的 bucket。

Azure 的 Storage Account 分为三种产品，分别是 Blob，Data Lake Gen1 和 Data Lake Gen2。其中 Data Lake Gen 1 已经不允许新用户创建了，只有存量用户可以用。Blob 和 Data Lake Gen2 的区别就是 Data Lake Gen 2 提供了一些元信息，使得你在执行 list 的操作时，性能更好，这点对 Hadoop 生态的用户非常重要。所以如果你是打算在存储上面跑 Hadoop，推荐使用 Data Lake Gen 2。当然喽，这个会更贵。然后奇葩的一点是，在 Azure 的官方 SDK 中，Blob 和 Data Lake Gen 2 用的 API 是不一样的。。。

Azure 的存储是没有 region 的概念，而且也没有什么协议的概念，不像 S3 和 GCS，分别有个 s3:// 和 gs:// 前缀。Azure 所有的文件都是一个 url。这个设计的初衷不错，可就是难为 Hadoop 了。Hadoop 在创建 FileSystem 的时候，会根据 URI 的 schema 来创建 FileSystem，而对于 Azure 来说，那就无计可施。

为了解决这个问题，Hadoop 发明了一系列的前缀：

• wasb[s]:// ：对应 Blob Storage
• adl://：对应 Data Lake Gen1
• abfs[s]://：对应 Data Lake Gen2

其中 [s] 加上表示开启 https。

好了，上面扯远了，讲了一堆 Azure 的存储。下面说说鉴权。

Access Keys

和普通存储一样，Azure 为其存储提供了类似 AK/SK 的机制，叫 Access Keys。

Azure 贴心的为你提供了两组 key，方便你进行泄露。当然这个 access keys 是可以在该 storage account 下的 configuration 里面关了。

Shared access signature（SAS）

SAS 是我个人比较喜欢的一种鉴权方式，它不需要一堆 user，policy，role 的概念，又能和 Access Key 一样简单，但它又比 Access Key 安全了许多。

其实原理也很简单，就是基于你当前的 Access Key，附加一堆权限控制的信息，然后基于某个算法生成一个新的 token。这个 token 天然的自带权限控制，过期时间，相比于 access key，安全许多。而且使用者也不可能基于 sas 倒推出你的 access key。这套其实和七牛，又拍云它们的签名算法差不多。一下子就想起若干年前手撸又拍云的上传签名算法，想想自己当时也真傻，掉包他不香吗。

Managed Identity

Azure 提供了类似 AWS 的 instance profile 机制，就是能直接把权限附加在 virtual machines 上面。

首先去 Managed Identities 里面创建一个 managed identity。

然后去 virtual machine 上面绑定自己刚刚创建的 managed identity。点击 Identity 菜单，就可以添加。

但是注意一点，此时这个 identity 是没有任何权限的，比如我们需要允许这个 identity 访问某个 storage account，那需要到 Storage account 给它添加上对应的权限。

在 Storage account 里面的 IAM 进行 role assignments。

假设要给该 managed identity attach 上一个 Storage Blob Data Owner，在这里，蛋疼的点来了。你点击 Select members 后，右侧你是看不见你创建的 managed identity，只有你创建的 user。这时候你要搜你的 managed identity 名字，下拉框就会自动出现了。

自此，你就完成了类似 AWS 的 instance profile。

Oauth2

Azure 支持 Oauth2 形式的鉴权，其在一定的程度上，就是 AWS assume role 的替代品，但是又比 assume role 复杂，因为你得先对 oauth2 有一定的了解。

首先在 Azure Active Directory 中的 App registrations，点击 New Registration，注册一个应用，我一般选择 web。

然后进入这个 app，点击 Certificates & secrets，创建一个 client secret。

最后你点击这个 app 的 Overview，关于 Oauth2 的信息都在里面，包括 Endpoint。

一般只会用到 Endpoint，Application(client) ID， Directory ID 和你刚刚创建的 secret。

注意，一个 Azure Active Directory 下面所有的 app 的 Directory(tenant) id 都是一样的哦。

同样，你初始创建的 app 是没有任何权限的。你需要和 Managed Identity 一样，去对应的资源下的 IAM，添加相应的 role。老道理，这个 Select members 弹出来的搜索框里面默认是不会有你的 app 名称，需要你手动输入 app 名字，就能找到了。

小结

当然，Azure 的鉴权远不止于这些，但是其它都是大同小异了，反正就是围绕着 Azure Active Directory 一顿捣鼓。Azure 给人的感觉就像是一个博士生，读了很多业内先进的论文，然后发明了一个非常牛逼的 IAM 系统。但是带来的代价就是难懂，用户真的有这么复杂的场景吗？

Google Cloud Platform（GCP）

在 GCP 里面，user 叫 service account。同时 GCP 和 Azure 一样，拥有层级系统关系，即一个 GCP 账号下面有多个 project，所有的资源都只能在某个 project 下面。

AK/SK

其实 GCP 里面是没有 AK/SK 的，但是在 Google Cloud Storage（GCS）中，为了兼容其它云厂商（其实就是 S3），它在 GCS 里面实现了一个 AK/SK，你可以在 Cloud Storage 中的 INTEROPERABILITY 里面创建 AK，SK。但是这个 AK/SK 的权限范围很大，其能够操作你这个 porject 下面的所有 buckets。

Compute Engine service account authentication

Google 也有类似 AWS instance profile 的东西，你在 Compute Engine 里面，可以为你的 compute engine 添加相应的 PERMISSIONS。你可以给他 attach 一个 service account，或者直接给他 attach 一个 role，都可以。但是比较挫的一点是，Compute Engine 里面修改 permission，需要确保你的 Compute Engine 处于关机状态。

Service Account

你可以理解为就是一个 user，和 AWS 的 user 一样，创建的时候你可以给他 attach 上一个 role。这个 role 上面可以 attach 了一堆 policy（oh，不对，在 Google 里面，应该叫 permission）。然后你可以为这个 user 创建一个 key，这个 key 是一个 JSON 文件，之后你就可以拿着这个 json key 到处晃了。

小结

GCP 这块的 IAM 没怎么说，反正大家都是大同小异了。

总结

	AWS	Azure	GCP
AK/SK	支持，绑定在 User 上面	不支持，只有 Access Key	只有存储支持，在 INTEROPERABILITY 里面
绑定在服务器上的 credential	支持，Instance Profile，绑定的是 Role（需要配置 trusted relationship）	支持，绑定的是你创建的 managed identity	支持，绑定的是 service account

其余的其实就是大家各自有各自的特色，没有太大的共同点。

文章写的英文单词一会大写开头，一会小写开头，请大家不要介意，随意看看，我也懒得改了。