[Day5] Project,IAM (2021 鐵人賽 – Cloud)


今天要來介紹的是,剛進入雲端一定會面對到的部分: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 帳號
      • 例如 meow@gmail.com
    • Cloud Identity 是屬於公司、機構內的認證方式
      • 例如 meow@meowmeow.com
  • Google Group 帳號
    • 例如 meow@googlegroups.com
  • 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,虛擬機。


發表迴響