AWS IAM, 从入门到依旧在入门

IAM 全称是 Identity and Access Management, 是 AWS 提供的一个服务, 用来控制对 AWS 资源的访问权限. 一句话概括就是:

IAM 核心就是把资源(Resource)上的操作(Action) 授权给谁(Identity)

既然是控制权限, 说白了就是对某个资源(后文统称 Resource) 的某些操作(后文统称 Action) 的控制.

那么学习 IAM, 首先搞清楚三个基本的问题:

  1. 如何优雅的定义 Resource? 如果有一个统一的规则, 来为 Resource 命名就再好不过了
  2. 如何优雅的定义 Action?
  3. Identity

0x00 如何优雅的定义 Resource

AWS 给出的答案是: ARN (AWS Resource Namespace). ARN 是一个命名规则, 用于无歧义的对 AWS 的资源进行命名.

ARN 的格式如下:

arn:partition:service:region:account-id:resource
arn:partition:service:region:account-id:resourcetype/resource
arn:partition:service:region:account-id:resourcetype:resource
  • partition 是分区. 通常情况下, 是 aws, 但由于不可抗拒的因素, 中国区的 arn 都是使用 aws-cn, 例如: arn:aws-cn:s3:::your-bucket-name
  • service 就是 AWS 各个服务的名称, 具体列表参见 AWS Service Namespaces. 需要注意的是, 不是所有的服务都使用了首字母简写. 例如, Elastic Compute Cloud 使用 ec2, 但 Elastic Load Balancing 却使用 elasticloadbalancing
  • region 是 AWS 的区. 中国北京区就是 cn-north-1
  • account 是自己的 AWS 账户的数字 ID
  • resource, resourcetype:resource, or resourcetype/resource 就是具体资源. 参见官方文档 Paths in ARNs

0x01 如何优雅的定义 Action

Action 也就是针对 AWS 上的服务提供的 API. 完整列表参见 AWS Service Actions and Condition Context Keys for Use in IAM Policies. 迄今为止, AWS 不知不觉已经提供了几十个服务, 几百个(或者更多) API. Cloudonaut 公司做了一个 Complete AWS IAM Reference, 方便查询 Action, 推荐使用.

至于 Condition Context Keys, 是 AWS IAM 中支持的一个功能, 即在定义 Policy 时可以使用一些变量, 支持复杂的表达式. 比如 ${aws:username}. 感叹一句: IAM 的配置就是让你用 JSON 语法写代码.

Every Configuration File is a Programming Language

0x02 Identity

Identity 就是最终把权限赋予给到的实体. IAM 中有三种 Identity, 分别是 User/Group/Role

  • User 就是 AWS 的用户, 可以用来登录 AWS Console, 也可以有访问秘钥调用 AWS API 等.
  • Group 就是用户组, 用于管理一组用户的权限.
  • Role 是角色, 需要被委托给 User 或者 AWS 服务, 使得被委托的实体有对应的权限
Identity 关系

熟悉了 IAM 的三个最基本元素, 还剩下最后一个: Policy

0x03 Policy

Policy 就是权限声明文档. 具体包含几个部分:

更多关于 Policy 如何写, 可以参见官方文档 Overview of IAM Policies

从类型上分, Policy 分为三种:

  • AWS managed policy: AWS 官方定义的模板 Policy, 按需直接使用即可
  • Customer managed policy: 客户自己定义的 Policy 模板, 可以将定义好的 Policy 挂到各种 Identity 上, 例如挂到一个 Group 上.
  • inline policy: 仅仅在当前 Identity 下可以用的 policy, 不能复用.

既然一个 User 可以属于多个 Group, 那么一个 User 会有多个 Policy 对其进行约束, 那么难免一个 Identity 所有的多个 Policy 会发生冲突. IAM 采用的策略可以概括为8个字: 凡事声明, 一票否决

  • 凡事声明: 默认情况下, Resource 是禁止访问的; 只有显式声明了对资源的 Allow 权限, 才允许访问
  • 一票否决: 即便是有 Policy 开启了 Allow, 一旦其他 Policy 中出现对 Resource 的 Deny 声明, 一律 Deny

详细文档参见官方文档 IAM Policy Evaluation Logic

0x04 IAM Policy Programming 小助手: Simulator

既然 Policy 的书写那么麻烦, 写完的 Policy 是否靠谱就成了问题. AWS 官方通了一个 Simulator, 通过两种方式进行使用:

  • 在 AWS console 中使用 Simulator 直接检验自己的 Policy
  • 调用 AWS IAM 的 simulate-custom-policy API, 直接通过 API. 也可以直接使用 AWS cli

Simulator 仅仅验证提交的 Policy, 不会执行任何真正的操作, 可以放心使用.

关于 simulator 的使用, 具体参见官方文档 Testing IAM Policies with the IAM Policy Simulator

具体关于 IAM 的入门, 就这么多.

0x05 Best Practice (As Far As I Know)

说了这么多, 总结一些最佳实践

0、 通读 AWS 官方文档 AWS IAM Best Practice

不多说. 谁读谁知道.

1、强制贯彻最小权限原则 (Principle of Least Privilege)

AWS 官方文档也有提到, 这里做一点补充. 有几个小的建议

  • 在 Policy 文件中的 Action 定义, 尽量少使用 *, 明确所有 Action
    • 比如 s3 中, s3:Delete* 不仅包含 DeleteObject, 还包含 DeleteBucket, 你想象一下
  • 如何确定某个 Role 需要哪些权限是给多了, 强烈建议开启 AWS CloudTrail 服务, 写一个脚本, 通过遍历 CloudTrail 数据确定

2、 能用 IAM Role 解决的问题, 不用明文 AWS Key

固定的 Key 有泄露风险. 但容器时代很多公司使用 k8s + docker, 无法使用 IAM Role, 推荐使用 Terraform 出品的 Vault 来管理 AWS Key, Vault 支持 Key Rolling 功能, 类似 AWS STS 的动态 Key, 提升安全性.

3、 尽量简化 IAM Policy 配置

虽然 IAM Policy 功能非常强大, 支持通配符 * 也支持表达式, 例如 StringEqualsIgnoreCase. 但不要忘记的是: 代码是给人读的, IAM Policy 也一样.

4、 尽量使用 git 等版本管理工具管理 IAM Policy

AWS 官方仅仅提供 Policy 的版本管理, 而且最多保存 5 个版本, 并且没有注释. 建议使用 Terraform 管理 AWS IAM.

0x06 借(copy)鉴(cat)

AWS IAM 设计的逻辑非常清晰, 借鉴意义很大. 设想, 如果你要在公司设计一套权限管理系统, 是不是可以借(copy)鉴(cat) IAM?

步骤都给你写好了, 拿走不谢:

  1. 定义 Resource 编码原则: 例如 lrn:department:team:resource_type/resource
  2. 定义每个 Resource 上的 Action. 微服务时代, 如果是使用 gRPC 就更好了, 直接将统一的 protocolbuffer 的定义解析一下, 就可以知道有哪些 service 的哪些 method 了
  3. 定义 Identity. 建议直接参考 AWS 的设计: User/Group/Role
  4. 定义 Policy 语法. 这里可以微创新一下, 不用 JSON, 哪怕选择一个支持注释语法的文件格式(比如 yaml)
  5. 实现 Policy Evaluator. 解析 Policy 给出裁决结果
  6. 接入各个系统, 收工.

0x07 总结

这只是 AWS IAM 的简单入门介绍!
这只是 AWS IAM 的简单入门介绍!
这只是 AWS IAM 的简单入门介绍!
(重要事情说三遍)
AWS IAM 还有很多新奇的玩法, 大家自己去探索吧. 最后推荐一篇写的非常好的 AWS IAM 文章: AWS IAM Policies in a Nutshell

Reference

-- EOF --

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,015评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,262评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,727评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,986评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,363评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,610评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,871评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,582评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,297评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,551评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,053评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,385评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,035评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,079评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,841评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,648评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,550评论 2 270

推荐阅读更多精彩内容