[Day5] Project,IAM

今天要来介绍的是，刚进入云端一定会面对到的部分：Project以及 IAM。我觉得这个相关的主题会是云端里面数一数二无聊的 QQ，但以一个完整的云端架构而言，这却是非常非常重要的部分。特别是 IAM 这个主题，单纯这个主题，事实上身为一个云端管理者、架构师，就可以上一整个月的课程了。

Project

任何的 GCP 服务，都会属於一个 Google Cloud Console 的 Project，无论是管理 API 、 管理计费方式、增加其他的协作者等都是基於 Project 为单位，而一个 Project 底下则可以有许多的资源 (Resources)。

一个 Project 可以包含非常多的使用者，且每个 Project 都是一个独立的单位，独立的隔间，他们会分开的计费。

每一个 Project 会有三个相关的识别属性

• Project ID
  • 可以自己定义，它必须是 Global Unique 的
  • 设定完後就不可更改
• Project Name
  • 可以自己定义，不需要 Unique
  • 设定完後仍然可以再次修改
• Project Number
  • 不可自行定义，由 GCP 自动产出
  • 不可自行更改

Project 阶层式管理

GCP 也可以透过阶层式的进行管理，以一个公司为例，通常会使用组织节点 (Organization Node)，而一个公司底下可能会有不同的部门，这个时候就可以透过资料夹 (Folders) 进行管理，而每一个部门底下也可能会有多个 Project；每个 Project 底下则又可以有多个 Resources，范例如下图所示。

图片来源：Google Cloud Creating and managing Folders

不同的资料夹间，可以设定不同的 IAM 权限管理政策，通常来看，整个公司架构的树状图中，位居越高位的管理权限越大，而越下面的权限越低。

IAM

Identity and Access Management (IAM)，身分以及访问权限管理，是云端管理之中，最最重要的一件事情。如果一个 IAM 的阶层管理做得越完善，越齐全，就越不可能会遇到一些看起来很荒谬的事情。

例如上述的新闻中，抖音公司的实习生误删了资料库，包含了 ML 平台的 Batch 模型全部都被误删。先不考虑官方要嫁祸给实习生的部分，如果说新闻真正属实的话，那我们就可以断定说抖音公司的各种 Policy 可能设计的不够完善。

在订定各种权限控管时，我们最需要注意的重点是，权限能设定的越小越好，负责 A 专案的人就只能修改，更动 A 专案，尽量以不让他接触到其他不属於他的资源为原则。

GCP 在 IAM 的定义上依照了 3 个元素。Who can do what on which resource。

Who (谁)

在 GCP 的 IAM Policy 当中，有 4 种 Who 的定义，

• Google Account or Cloud Identity user
  • Google Account 是大家常见，习惯的 Gmail 帐号
    • 例如 [email protected]
  • Cloud Identity 是属於公司、机构内的认证方式
    • 例如 [email protected]
• Google Group 帐号
  • 例如 [email protected]
• Cloud Identity or G Suite domain
  • 假设公司先前的架构有使用到微软的 AD，或是 LDAP 等使用者管理，则可以用 Google Cloud Directory Sync 的技术，将使用者汇入为 Cloud Identity
  • G Suite 相信大家都不陌生，公司、学校等机构都可以透过 G Suite 建立帐号与群组。
• Service Account
  • 我们也可以设定一个帐号是专门给 Services 使用的，例如说我想要设定一台 VM，当他自己觉得他不够用时，就透过指令再开一台的 VM，在这种情形下，我们就需要设定一个 Services Account 给这台 VM ， 并给予他新增机器的权限。

Can do what (可以做什麽事)

Can do what，可以做什麽事情，这边我们又可以把一个 Role 分成了三个部分，Service (服务)、Resource (资源) 与 Verb (动词)。

例如说我们有一台 Compute Engine 的云端 VM instances，我们可以设定有一个 IAM 中的使用者，只能帮他进行开机，而不能进行关机以及删除，这种时候我们就可以设定他的 Services 是 compute ； 他的 Resource 是 instances；而 Verb 则是 start，我们可以给予该使用者一个 Role 为 compute.instances.start，就能完成这样的功能。

On which resource (在什麽资源上)

我们可以将上述的 role 套用在指定的 Project 或进一步的资源内，或是各种的服务上，举例来说，我可以设定使用者只能操作指定的 Project 内的指定资源，只能帮指定的云端 VM 进行开机等。

IAM 预设的 Role

相信大家看到这边，一定觉得如果我公司有上百个人的话，一行一行的帮所有人写 role 是一件很辛苦的事情，所以 Google 也提供了 3 种 IAM role 可以供大家快速套用。这边的 Role 主要就是定义 "Can do what" 的部分。

Primitive Role

在 Primitive Role 中，我们可以把使用者分成 4 个部分。

• Owner (拥有者)
  • 可以做的事情最多，包含了......
  • 邀请、删除新成员
  • 删除 Project
  • 以及所有编辑者可以做的事情
• Editor (编辑者)
  • 编辑者可以......
  • 部属 Application
  • 修改 Code
  • 修改 Services 的设定
  • 以及所有 Viewer 可以做的事情
• Viewer (观看者)
  • 观看者就仅有唯读的权限，不能进行任何的更动
• Billing administrator (计费管理员)
  • 计费管理员主要负责处理各种计费相关的服务
  • 他可以增加与移除管理员

Predefined Role

相较於 Primitive Role，Predefined 的规则会更加的细致一点点，我们可以不用把所有有编辑权限的人都设定为 Editor。例如说，我们可以选择一个预设的 InstanceAdmin 的 Role，而这个 Role 就内建了许多精细的 Role。他内部包含了：

• compute.instances.delete
• compute.instances.get
• compute.instances.list
• compute.instances.setMachineType
• compute.instances.start
• compute.instances.stop
• ......等

Custom Role

而通常足够大的公司，需要将权限分的够细的话，就需要透过 Custom Role 了，可以设定到最细的，哪一个人，拥有怎麽样的权限。

总结

今天的内容真的是又臭又长阿 QQ ，身为一个初学者，我们只需要知道，Google Cloud 的所有资源上面都要有一个 Project，而 Project 上可以用各种资料夹进行阶层式的管理；每一个云端的使用者都可以设定自己的云端 Policy，而这些权限都要越小越好，以免发生意外，存取到不属於他的资源；真的发生意外时，也可以让灾害降到最小。

今天的内容就到这边，明天预计来跟各位介绍一下云端最简单最常用的资源：VM，虚拟机。