# 快速了解 Google Cloud Platform IAM
常常聽到 IAM，在公司使用 Google Cloud Platform (以下簡稱 GCP) 時也有遇到權限不足需要去申請的時候，但根本不了解裡面的內容，趁著最近讀完官方文件後簡單的寫個筆記。

<br>

## What is IAM?
在 Google Cloud API 中的權限控管 (Access control) 可以大致拆分成三部分:
1. Authentication
2. Authorization
3. Auditing

其中 Authentication 負責識別你是誰，Authorization 決定你能做什麼事，Auditing 則是記錄你做了什麼事，其中 Authorization 就是本文提到的 **IAM**。

**IAM** 全名是 **Identity and Access Management system**，顧名思義就是管理身分與權限的系統，用一句話帶過就是定義了:

> **誰 (Identity)** 可以對某個**資源 (Resource)** 做哪些**操作 (Role & Permission)**

</br>

各大雲端服務都有自己的一套 IAM 系統 (如下表)，但彼此又有些許差異，本文會對 GCP 作說明。

| Cloud Service | Service |
| ------------- | ------- |
| Google Cloud Platform (GCP) | IAM |
| Amazon Web Services (AWS) | IAM |
| Microsoft Azure | Azure Active Directory (Identity Service) |

## IAM 架構中的成員

- Resources 資源
- Principle: 主體
- Role: 角色
- Permissions: 權限
- Allow Policy (Policy): 政策

彼此的關係如下圖:

接下來會一一介紹這些成員。

## Resource

Resource 代表 Google Cloud Platform (以下都簡稱為 GCP) 上的資源，resource 可以是 GCP Projects、Compute Engine 實例、或是 Cloud Storage 的其中一個 Bucket。

來看 Google 的範例:


## Principle

Principle 就是指一個身分 (Identity)，在 IAM 中被授權 (Authorized) 的對象，Principle 可以是下列身分中的任何一種:

1. Google Account
2. Service account
3. Google group
4. Google Workspace account
5. Cloud Identity domain
6. All authenticated users
7. All users

### Google Account

任何關聯成為 Google 帳戶 (Google Account) 的 E-mail 地址都可以做為一個 IAM 中的身分且不限域名，例如: `[e-mail]`、`[e-mail]`。

### Service account

如果說 Google Account 背後代表的是一位使用者，那服務帳戶 (Service Account) 代表的就是一個服務或是一支程式。假設我有一支背景運行的程式執行在非 GCP 環境，且會定期在某個時間把檔案上傳至 Cloud Storage，這支程式該使用的身分應該是服務帳戶而非某個人的 Google 帳戶。

### Google group

Google 群組 (Google group) 指的是一個包含 Google 帳戶以及服務帳戶的集合，這個集合會有獨一無二的 E-mail 地址來表示，例如你屬於資料科學部門可能就會被加入某個 `[e-mail]` 的群組內，`[e-mail]` 可能同時包含了整個資料科學部門的人員以及專案中有用到的服務帳戶。

### Google Workspace account

Google Workspace 其實就是原本的 G Suite，代表一個抽象 Google 帳戶集合，他並不像 Google 群組一樣是把好幾個帳戶一一列出來組成群組。舉例來說，某個組織使用了 Workspace 服務，並註冊 `xxx.com` 這個域名，並用這個域名幫所有員工都註冊了類似 `[e-mail]`、`[e-mail]` 的 Google 帳戶，那在使用 IAM 的時候可以一次性的使用 `xxx.com` 來管理組織下的權限。

### Cloud Identity domain

類似 Workspace Account 的身分，差別只在於說有沒有使用 Workspace 的服務，例如某間公司想使用 GCP 但是不需要使用到 Workspace (G Suite) 提供的服務，那就可以開一個 Cloud Identity domain 使用自己的域名來管理權限。

### All Authenticated users

`allAuthenticatedUsers` 是一個特殊的識別，泛指所有已經透過 Google Account 驗證過的服務帳戶或其他帳戶，無論這些帳戶是否如屬於某個 Workspace 或是 Cloud Identity domain，即使是私人的 Gmail 帳戶也包含在內，但不包含沒登入或匿名訪客。

### All users

`allUsers` 是另一個特殊識別，顧名思義就是所有在網路上的使用者，包含已登入及匿名訪客。

## Permission

在先講解角色 (Role) 之前要先說明權限 (Permission)，權限在 IAM 中會用這樣的表示法來表示對某個資源的一個動作 (Action): `service.resource.verb` 。

我們先來看一個 GCP 權限 `storage.buckets.create`


其中，storage 代表的是 Cloud Storage 這個服務，buckets 代表 bucket 這項資源而 create 就是只能建立這個資源，擺在一起看就是有這個權限的角色 (Role) 就能夠在 GCS 中建立新的 bucket。

通常每一項權限都會對到一個唯一 REST API，擁有這個權限的角色可以直接呼叫 API 來執行這個動作。

## Role

角色 (Role) 就是一群權限 (Permission) 的集合，在 IAM 中無法直接把某個權限指派給某個主體 (Principle)，而是綁定 (Binding) 具有權限的角色給主體，在 GCP 中會很常看到一個角色的表示為

`role/` 這個 prefix。

在 IAM 中角色有三種:

1. Basic roles
2. Predefined roles
3. Custom roles

### Basic roles

凌駕於一切的角色的 Basic Roles 有三種:

| Role | Description |
| -------- | -------- |
| Viewer(roles/viewer) | 只擁有唯獨權限的角色，無法進行編輯|
| Editor(roles/editor) | 擁有所有 Viewer 有的權限還加上編輯(CRUD) 的權限 |
| Owner(roles/owner) | 所有 Editor 有的權限加上: </br>1. 管理專案中的所有權限 </br>2. 可以管理帳務

要注意的是， Basic roles 只能綁定給專案，且擁有上千種 GCP 權限，在正式環境中不建議直接使用，取而代之使用 IAM 幫你準備好的 Predefined roles。

### Predefined roles

相較於一次用有超級多權限的 Basic role，IAM 針對不同服務提供了各種量身訂做的角色，這些角色會由 Google 來創建及維護，當有新的服務或功能加入時，這些角色的權限也會跟著擴充，好處是在正常情況下，只會給予主體最低限度的權限而不用擔心衍生額外的問題。

來看一個 Predefined role 的例子:

| Predefined role | Permissions |
| --------------------| ----------- |
| roles/storage.admin | firebase.projects.get |
| | orgpolicy.policy.get |
| | resourcemanager.projects.get |
| | resourcemanager.projects.list |
| | storage.buckets.* |
| | storage.multipartUploads.* |
| | storage.objects.* |

### Custom roles

如果 Predefined roles 沒有辦法滿足你的需求，也可以為自己的組織或是依據喜好來建立客製化的角色。

## Allow policy

IAM policy 或稱政策 (policy) 就是將主體和角色作綁定的宣告，關係如下圖。


在這個宣告中會有兩種角色:

1. Role
2. Members

### Role

要被綁定的角色，包含了想被授權的各種權限

### Members

要被綁定的成員清單，可以是多個主體，每個主體都會有專屬的前綴來識別是哪一種類別，例如
Google Account 會用 `user:` Service account 會用 `serviceAccount:` 等等。

來看一個 allow policy 的結構:

{
  "bindings": [
    {
      "role": "roles/storage.objectAdmin",
       "members": [
         "user:[e-mail]",
         "serviceAccount:[e-mail]",
         "group:[e-mail]",
         "domain:google.com"
       ]
    },
    {
      "role": "roles/storage.objectViewer",
      "members": [
        "user:[e-mail]"
      ]
    }
  ]
}

當一個政策宣告完後，會被連到特定的資源，就完成了文章開頭提到的

> **誰 (Identity)** 可以對某個**資源 (Resource)** 做哪些**操作 (Role & Permission)**

這樣的一個關係。

## Links

IAM overview (推薦讀完): [https://cloud.google.com/iam/docs/overview](https://cloud.google.com/iam/docs/overview)

Principles: [https://cloud.google.com/iam/docs/understanding-roles#predefined_roles](https://cloud.google.com/iam/docs/understanding-roles#predefined_roles)

Roles: [https://cloud.google.com/iam/docs/understanding-roles](https://cloud.google.com/iam/docs/understanding-roles)

Permissions: [https://cloud.google.com/iam/docs/permissions-reference](https://cloud.google.com/iam/docs/permissions-reference)