當你開始使用 GCP 的專案，你就是這個這個專案的最高管理員，稱為「專案擁有者」(Project Owner)。 

你可以管理這個專案中的所有資源，愛怎麼用就怎麼用。

但如果你今天是在一家公司裡，一個專案可能會跟同事或其他部門的人一起使用， 如果企業夠大，有專業分工，甚至會有管理網路的、管理主機的、管理負載平衡的、還有專門管理帳單的人。 

所以我們就必須切分成不同的權限，讓大家各司其職的同時，不影響其他人的操作，也能兼顧資訊安全，這就是為什麼我們要了解 Cloud IAM。

一、Cloud IAM 簡介

(一) Cloud IAM 是什麼？

Cloud IAM，全名 Cloud Identity and Access Management，直譯為身份和存取管理。

就是 GCP 的角色和權限管理系統，管理「誰」可以進入「某個區域」做「什麼事情」。

由此可知它有三個元素：

1. 「誰」指的就是一個身份

又叫做「主體」(Principal)。

2. 「某個區域」就是「資源」

像是 VM、Disk 或 Cloud Storage Bucket 都是資源。

3. 「什麼事情」指的是具體的操作行為

也就是細分的權限，例如建立 VM、修改 VM 參數、讀取 VM、刪除 VM 等等。

所以 Cloud IAM 就像是 GCP 的門禁系統，確保「對的人」可以存取「對的資源」，並且只能進行「被允許的操作」。

(二) Cloud IAM 有什麼前提？

這裡指的是 Cloud IAM 可以管理的帳號，分成以下幾種狀況：

如果你本來就是使用 Gmail 或是 Google Workspace，當你啟用 GCP 的環境，你的帳號就可以直接用在 Cloud IAM。 

如果你使用的不是 Google 的帳號，例如你可能使用微軟的 M365，或是其他的郵件系統，你會看到像這樣的錯誤訊息：

代表這並不是一個 Google 帳號，你就必須要申請 Cloud Identity，讓你能夠建立 Google 的帳號， 這樣就可以使用 Cloud IAM 了。

而可以被授權 Cloud IAM 角色的對象我們稱為主體 Pricipal，而這個主體並不是只有帳號，還包含了 Google Group (群組)，還有 Service Account (服務帳號) 跟網域，這些都是都是可以在 Cloud IAM 裡面，被賦予角色權限的對象。 

二、Cloud IAM 的角色與權限的介紹與運作方式

(一) Cloud IAM 的角色與權限的關係

在 GCP 的專案環境中，每一個對資源的操作，有可能包含一個以上的權限，像是建立一台 VM，可能至少包含以下權限：

• compute.instances.create  (建立 VM)
• compute.disks.create (建立開機磁碟)
• compute.networks.use (讓 VM 連接到某個 VPC)
• compute.subnetworks.use (讓 VM 連接到某個 Subnet)
• compute.images.useReadOnly (使用一個作業系統的 Image，例如 Ubuntu)

而目前在一個 GCP 專案中，截止目前 (2024年11月21日)，已經有超過 10000 個細分權限，如果我們直接設定這 10000 個權限分配，應該會設定到懷疑人生。

而且這個權限數量，還隨著 GCP 新推出的服務持續增加當中。以專案擁有者，幾乎擁有全部的權限數量如下：

為了簡化管理，GCP 把相關的權限群組起來，依照使用的場景或是執行的操作， 劃分成不同的「角色」 ，這樣我們就能方便地管理大家的權限。 

補充一下，GCP 的帳單角色，不直接屬於專案，而是和帳單帳戶 (Billing Account) 綁定的，運作方式有些不同，未來會再專文討論。

(二) Cloud IAM 的角色類型

Cloud IAM 的角色有三大類，分述如下：

1. 基本角色 (Primitive Roles)

之所以叫「基本」，就是以簡單粗暴的方式來劃分權限，許多小公司或個人使用者都是用這類的權限，就是因為簡單，我們從權限由大到小說明如下：

(1) 擁有者 (Owner)

當你第一次進入 GCP 主控台，GCP 會用你的身份來建立一個專案，而你就是專案的擁有者。

你擁有在這個專案裡全部的權限，看得到所有資源和資料，也可以任意更改，你也能夠管理任何帳號被分配的角色和權限。

(2) 編輯者 (Editor)

編輯者能看到專案內所有資源的內容，也都能修改，像是開機器、關機器、建立負載平衡器，這些都做得到。

編輯者和擁有者的權限很接近，就差在不能管權限，你沒有辦法授權別人進來這個專案，或者是把某個成員踢掉。

(3) 檢視者 (Viewer)

檢視者在這個專案裡面的東西，你全部都可以看，可是你不能改，但是全部都看得到，權限也是蠻大的。

你可以看到專案內開了幾台機器、所有的 Cloud Storage Bucket 都能點進去看儲存了哪些檔案、 BigQuery 裡面有哪些表格和裡面的資料，全部都看得到，甚至可以下載到你的電腦上。

(4) 瀏覽者 (Browser)

瀏覽者的權限是最小的，它只能讓你知道，手上有一個專案叫做 dong-dong-gcp-4-cloud，並且能夠進入資訊主頁，看到這個專案的基本資訊，僅此而已，但裡面所有資源的內容都完全看不到。

2. 預先定義的角色 (Predefined Roles)

由於基本角色的權限劃分比較簡單粗暴，方便好用，但這種方式給出的權限都有一點太大了。

對於公司規模較大，在部門專業分工的情境下，就可以使用預先定義的角色。 這種角色就是依照使用者在公司賦予的任務之下，授權相對應的權限。 

例如：

(1) 只管虛擬機器的人，就可以給他執行個體管理員 (Compute Instance Admin)；

(2) 管理 VPC 和 Subnet 的人，可以授予 Compute Network 管理員；

(3) 管理防火牆的人可以授予 Compute Security 管理員； 

(4) 管理上述全部的人，可以直接授予 Compute 管理員；

(5) 而管理整個專案資訊安全的人，卻又不管理虛擬機器和網路的人，可以授予 Security 管理員。 

這樣感覺很複雜，我們整理如下表：

你可以看出，每個權限都可以縱向擴充 (網路相關權限包含資安)，或是橫向擴充 (資安相關權限包含網路)。

而且不是只有管理員，GCP 的每一個服務也都能再細分成編輯者和檢視者。

而且上述只針對虛擬機器和網路，GCP 還有各種服務如 Cloud Storage、Cloud SQL 和 BigQuery，各自又區分出不同的角色。由此可見，角色區分地非常細。 

只要公司有對於權限或資安有較高的標準和規劃， 都可以依照分工和職責去給予不同的角色。 但反過來說，也會需要專人來負責管理權限劃分，以免造成授權混亂的情形。

3. 自訂角色 (Custom Roles)

因為預先定義的角色是用服務或屬性來劃分每個角色擁有的權限， 但是如果一個人的職責橫跨不同的服務，例如他同時管理虛擬機器和 Cloud SQL 資料庫，你就必須同時給予兩種角色，或是使用一個自訂角色配上相關的權限。 

這種方式可以對每個人的權限做最細緻的管理，做到「剛好必要」的權限分配。但這就需要一個專門的人員，除了了解 GCP 的每一項操作產生的結果，也要知道該行為涉及哪些權限。

因為當這個制定角色開通並且授權出去之後 ，使用者可能會在過程中會發現提出某個功能的操作權限不足，然後再回報給自訂角色管理人員， 來來回回重複確認和測試，並且調整權限，過程會很耗時。 

而且這個過程很有可能是會持續發生的，隨著使用者對於 GCP 的操作越來越深入或廣泛， 所以會持續提出增加權限的需求。 

同時  GCP 的服務也會持續的成長，每個服務的功能也會越切越細，導致新的權限不斷產生，然後再持續調整授權。 如果沒有專屬的角色管理人員來處理的話， 很容易讓權限管理變得混亂。 

因此通常建議使用預先定義的角色就好，除非公司專業分工到了極致，再考慮使用自訂角色。

(二) Cloud IAM 的基本授權操作

主選單有一個 IAM 與管理，進去後會直接顯示「身分與存取權管理」的頁面，它會列出在一個 GCP 專案內，所有帳號授權的角色有哪些，如果要授權給新的帳號，就點擊「授予存取權」。

接著在「新增主體」欄位輸入要授權的帳號，選擇要指派的角色，因為角色非常多，要慢慢找，或著是先去「角色」頁面看好要授權的角色，把名字複製起來，貼在角色的搜尋欄位裡面。

有一點要注意的是，如果你今天是授權專案擁有者給別人，系統會發信通知對方，但是其他角色的授權不會發信通知。

所以當你授權其他角色之後，你就把專案的網址直接傳給對方，讓對方方便進入你的專案操作。 

(三) Cloud IAM 角色和權限的繼承機制

上述只提到專案和資源的範圍，而在整個 GCP 的組織架構裡，總共分成 機構 (Organization)、資料夾 (Folder)、專案 (Project) 和資源 (Resource) 四個層級。

權限會從上而下繼承，代表在機構層級授予的角色，會應用到所有資料夾、專案和專案內的資源。

如上圖，如果你在 Team B 資料夾層級授權 Viewer 給同事，他就可以看到 Project 1 和 Product 2 底下所有的專案，以及專案之下所有的資源。

如果你在 Production Project 又授權 Editor 給同事，因為 Editor 角色涵蓋的權限比 Viewer 多，所以會覆蓋原本 Viewer 的權限，同事在專案就擁有 Editor 角色的所有權限。

在專案層級，如果你是在 Test 專案授權 Compute Instance Admin 給同事，他就可以連到 Test 專案裡所有的虛擬機器。

那假如只想給同事連到其中一台機器怎麼辦？

在 IAM 授權的介面中，還有一個條件 (Conditions)，這裡可以設定到最細的資源對象，甚至連授權的時間都可以規範，不過要注意目前還是 Preview 階段，建議多反覆測試再使用，詳細的說明可以參考這份文件。

三、Cloud IAM 設定中常見的注意事項

(一) 遵守最小權限原則 (Principle of Least Privilege)

1. 最小權限原則主要三個基本原則

(1) 使用者只能擁有完成其工作所需的最小權限，也就是剛好必要的權限。

(2) 如果可以的話，權限的範圍和時間都應該最小化。

(3) 預設拒絕所有權限，只開放必要的存取

2. 最小權限原則的比喻

可以想像成一個飯店的房卡系統：

(1) 住客的房卡只能開啟自己的房間。

(2) 清潔人員的房卡有時效性限制，例如從退房期限開始 (中午 12:00) 到新客入住之前 (下午 15:00)。

(3) 經理雖然是主管，但是他也只能進入辦公室區域，不能進入住客的房間。

3. 最小權限原則在 GCP 的正式做法

(1) 優先使用預先定義的角色或自訂角色

(2) 除非真的別無選擇，否則盡量不要用基本角色

(3) 可以使用 GCP 的「角色建議」和「政策模擬」來找出最適合的角色

角色建議 (Role Recommendations) 功能，它是由 IAM Recommender 所產生的，它會主動提示目前授予的角色，是否包含太多權限，確保你能夠遵守最小權限原則，詳細說明可以參考這份文件。

我們在 IAM 的主畫面就可以看到，它提示了某個授權設定包含 9003 個超額權限。

當我們點擊它所提示的超額權限之後，它會秀出建議替換的角色，並且分析權限數量的變化。

政策模擬器 (Policy Simulator) 功能則是讓你在變更某個帳號的角色時，讓你預先確認變更前後的差異。如下圖我把一個帳號從 Secret Manager 密鑰存取者改成Secret Manager 密鑰管理員：

若我們按下測試變更，會看到它模擬變更後會有什麼結果：

要注意它列出來的存取權變更，是根據前面 90 天的操作記錄來分析，如果你像我一樣，90 內曾經刪除過某些資源的話，它就會顯示「狀態不明或發生錯誤的存取權」，所以如果可以的話，最好能夠逐條確認變更後的影響。

(二) 個人帳號務必啟用兩步驟驗證

如果駭客今天不是駭入你的主機或程式，而是直接破解你的密碼，那它就有可能做出任何毀滅性的事情，例如瘋狂開你的機器來挖礦，或開啟殭化電腦去攻擊其他系統，所以這是根本且必要的步驟。

如果可以的話，最高管理員請使用 Security Key，長得有點像隨身碟，以後兩步驟驗證的第二步驟，就可以插入金鑰來驗證。

(三) 設置兩個最高管理員

如果你目前只有專案層級，那就是設定兩位擁有者，為什麼呢？

曾經發生過一家中小企業，老闆要工程師使用 GCP，但工程師用自己的 Gmail 來申請 GCP，而且沒有授權給老闆。有一天工程師離職了，沒有交接 GCP 的專案，直接人間蒸發，老闆從頭到尾都沒有被授權 GCP 專案，等於員工直接帶走公司的重要系統和資料。

如果為此向 Google 提交技術支援申請，Google 基於本身的條款，不會介入任何 GCP 的操作，就是不可能直接把那個專案還給老闆並且把工程師踢掉。

所以第一個方法就是至少要有兩位擁有者，第二個方法則是，不要用 Gmail，而是使用 Cloud Identity 來創建一個機構，如果工程師在專案是擁有者，老闆是機構管理員，還可能把專案的權限拿回來。

同理，如果你是已經有 GCP 的機構層級，那也要設定兩位機構管理員，一方面防止上述情形發生，另一方面則是防止帳號被駭客盜走，至少另一個帳號還有機會阻止駭客。

(四) 善用稽核記錄 (Audit Logs)

GCP 預設會自動記錄每個使用者的操作，如果有人做了什麼異常的行為，都會被記錄起來，但有些 Data Access Logs 預設沒有開啟，你可以評估有哪些重要服務要開啟記錄功能。

要注意額外開啟的 Log 會佔用 Cloud Logging 的儲存空間，如果想要節省費用，可以匯出到其他地方保存。

(五) 在機構層級管理跨專案存取的 IAM 政策

如果你有多個專案，在機構層級設定 IAM 的話，你只要設定一次就好，而不用每個專案都設定一次，如果公司常常新增或刪除 GCP 專案，這樣可以避免有哪一個專案沒設定到。

另外，可以針對部門成員建立群組 (Google Group)，這樣就可以透過群組統一授權，也能避免人員異動，而沒有被授權到相關權限。

最好的方式就是，各個部門都有各自的資料夾，資料夾底下就是部門自己擁有的 GCP 專案，然後資料夾直接分配授權給部門群組，或是主管，這樣就能更方便地管理全公司的 IAM。

四、 Service Account (服務帳戶) 簡介

Service Account 是一種特殊的 Google 帳戶，設計用來代表應用程式或服務，而不是人類使用者。它能夠執行指定的任務並存取必要的資源。

和人類使用的帳號比起來，Service Account 的使用頻率更高，像我們人類平日會上下班，假日會休息，而 Service Account 是和程式綁在一起，全年無休 24小時運作的，因此它更顯得重要，本文特別拉出來單獨說明。

(一) Service Account 的功能和特色

1. 提供應用程式授權，以操作 GCP 資源

Service Account 的主要任務之一是提供授權給應用程式，允許它們存取和操作 GCP 資源。

無論是存取 Cloud Storage 中的檔案，還是對 BigQuery 的表格查詢，Service Account 都能做為應用程式的「身份」，確保只有經授權的應用程式能與資源互動，避免未經允許的存取行為。

2. 基於身份和角色的存取控制

Service Account 在 Cloud IAM 中也是被授權的「主體」，你可以授予任何需要的角色來取得權限，讓 Service Account 能操作 GCP 的資源。

例如，某個 Service Account 可以被授權僅限讀取 Cloud Storage 資料，而另一個 Service Account 能被授權操作 Compute Engine 資源 (例如給 VM 開機或關機)，這種細微的權限控制提高了整體的安全性。

另一方面，上述提到的自訂角色，設定給一般使用者，由於使用者操作 GCP 所需的權限較多，實際執行起來有點麻煩。

但是如果是給 Service Account 使用自訂角色，反而是好的，因為你可以真的只給 1~2 條必要的權限，真正符合最小權限原則的精神。

3. 提供安全的 API 呼叫和資源操作方式

我們人類在 GCP 的任何操作，背後都是 AP 在運作的。而應用程式需要透過 API 與 GCP 服務互動時，Service Account 會以它的身份進行授權並簽署 API 請求。這樣能確保通訊的安全性，避免敏感資料在傳輸過程中被駭客攔截。

而且，Service Account 的 Key 還能進一步加密對 API 的呼叫，提供額外的保護。

(二) Service Account 的運作流程

如下圖所示，Service Account 的運作流程可分為以下四個步驟：

1. 應用程式保存著 Service Account Key 的 Json 格式金鑰檔案，裡面包含 GCP Project ID、Service Account ID 和 Key 的內容。

2. 當需要存取 GCP 服務時，應用程式使用這個 Json Key 來呼叫 GCP 的 API 進行身份驗證。

3. GCP 驗證金鑰的有效性，並確認對應的 Service Account。

4. 驗證成功後，應用程式可以使用該 Service Account 被賦予的角色和權限存取 GCP 服務。

(二) Service Account 的常見使用情境

1. 自動化工作流程

GCP 提供的 CI/CD 工具如 Cloud Build 和 Cloud Run，能幫助開發人員簡化軟體的編譯、測試與部署流程。

這些工具在運作過程中，通常需要訪問其他 GCP 資源，例如讀取 Cloud Storage 中的設定檔，或寫入結果至 BigQuery，此時就必須要使用 Service Account。

Service Account 為這些工具提供授權，確保它們能安全地訪問資源，同時避免人為操作的繁瑣與潛在錯誤。這不僅提高了工作效率，也降低了安全風險。

2. 跨系統間的安全通訊

應用程式通常需要在各個服務之間通訊或傳輸資料，例如從 Cloud Storage 中讀取資料，並透過 BigQuery 分析處理。而通訊必須以安全為首要考量，否則可能導致敏感資料洩露出去。

Service Account 可以充當服務之間的信任橋樑，透過授權的 API 呼叫，Service Account 確保只有經過允許的服務才能執行特定操作。

此外，它還能限制操作範圍，避免過多的權限導致潛在風險，這點非常重要。這樣的安全機制，不僅保護了資料的完整性，也簡化了跨服務整合的流程。

3. 第三方應用整合

在許多情境下，企業需要將 GCP 資源與第三方應用程式串接。例如，某些外部程式需要訪問您的 Cloud Storage 或監控你的虛擬機器的效能指標。為了保障安全，為這些第三方應用創建專屬門的 Service Account 是最好的方法。

專門的 Service Account 能夠以最小權限原則給予角色，只讓它存取必要的資源。同時，這種設計方式也能確保第三方應用與內部服務之間的存取控制是清晰且可管理的。

一旦某個第三方應用不再需要訪問資源，刪除其對應的 Service Account 就可以立即撤銷其權限，提升整體安全性。

(三) 如何建立和管理 GCP Service Account

1. 建立 Service Account

主選單「IAM 與管理」的「服務帳戶」，點擊「建立服務帳戶」。

接下來給 Service Account 命名，建議取一個容易了解的名字，或是設定一個命名原則，在說明欄也寫清楚這個 Service Account 的用途，讓其他人都看得懂。接下來按「建立並繼續」。

接者設定要授予 Service Account 的角色，這個動作在 IAM 的主畫面也可以設定，GCP 在這裡是給你方便一起設定，如果還不確定要授予什麼角色，也可以先跳過。

如果你按「繼續」，下一步驟是把 Service Account 的存取權給使用者，這一步請跳過！！直接按下完成。

你可能會覺得奇怪，這個步驟在做什麼？為什麼要跳過？

因為這個動作是把 Service Account 的使用權給使用者，使用者會取得這個 Service Account 的所有權限，例如使用者原本只有 Compute Instance Admin 角色，只能管理虛擬機器，結果他拿到一個 Service Account 的存取權限，而這個 Service Account 可以存取 BigQuery 所有的資料，等於這個使用者也能看到 BigQuery 的資料。

所以這個動作會讓使用者的權限範圍擴大，違反最小權限原則。

除此之外，使用者透過 Service Account 存取資料，會繞過正常的權限管理機制。因為系統日誌只會記錄 Service Account 存取資料的記錄，追蹤不到實際的操作者是誰，如果發生資安事件，也會阻礙調查。

就像你是大樓的管理員，Service Account 就像是公司的門禁卡，使用者小明是員工，GCP 的服務就像是大樓裡的不同房間。

小明只能進入一樓茶水間和三樓的辦公室，結果你把你的門禁卡給了小明，小明突然可以進入所有樓層，包括機密檔案室！

而大樓的監視器只會拍到「有人用公司門禁卡進出」，但不會知道用門禁卡的人是誰。如果小明把資料帶出大樓，或是銷毀，沒有人會知道是小明做的。

所以這個動作，除非你熟悉會有什麼後果，如果不懂最好不要授權給使用者。

按下完成之後，你可以點擊 Service Account 的名稱，進入它的詳細資訊頁面。

在這裡你會看到專屬 ID，如果你再展開下方進階設定，還會看到用戶端 ID，這些都是機密資訊，不要隨便分享。

尤其是「網域層級委派」，這是一個在 Google Workspace 中的「超級無敵大權限」，它可以看到公司內所有人的雲端硬碟檔案，如果不懂絕對不要設定。

2. 建立 Service Account Key

如果你的 Service Account 是要讓外部的應用程式存取 GCP，就要再建立 Service Account Key。這時我們再點擊「金鑰」頁籤。

下方會看到「新增鍵」，這是 Google 翻譯得不好，其實就是「新增金鑰」，然後再「建立新的金鑰」。

點擊之後會彈出一個視窗，問你 Service Account Key 的檔案要下載成什麼格式，通常我們都用 Json 格式。

按下「建立」之後，會自動下載金鑰檔案到你的本機電腦。

這裡要注意，我們只有在建立金鑰的這一刻，是唯一能下載金鑰檔案的機會，如果這次下載後，金鑰檔案弄丟了，那你是無法再次下載金鑰的。你只能再建立另一個新的金鑰，同時刪除舊的金鑰，以免舊的金鑰檔案被駭客取得。

下載完後，我們可以用文字編輯器打開檔案，像我是用 Firefox 瀏覽器打開，它能夠以 Json 格式呈現檔案的內容。

你會看到這個金鑰檔案包含 Project ID、Key ID、Key 的內容、Service Account 的 Email 等相關資訊，這些資訊就是應用程式要去呼叫 GCP 的 API 時，做身份驗證要提供的內容。

所以當你擁有這個金鑰檔案，你就有能力存取 Service Account 能存取的各項資源了。

這也代表你必須好好保管這個檔案，要注意「非常非常多用戶」因為沒保管好金鑰檔案，導致檔案被駭客拿走，在 GCP 的專案裡大肆破壞你的環境，或是開一堆機器在挖礦， 一天之內造成上百萬元的 GCP 帳單，是由你幫駭客買單，不可不慎！

(四) 什麼時候要使用 Service Account？

Google 在官網有提供一個決定是否要用 Service Account 的決策過程如下：

1. 你是否在單一使用者開發環境 (如個人電腦、Cloud Shell、個人用的虛擬機器、虛擬桌面)？

像這樣的環境通常已經有使用者登入，你可以直接使用個人的憑證，例如你可能就是專案擁有者，權限也夠大，所以在開發或測試時較為彈性，不會動不動就因為權限不足而卡住。

・是，往問題 4，因為可能有更簡單的驗證方式。

・否，往問題 2，可能是生產環境或共享環境，會影響到這些環境的正常運作，所以可能要使用 Service Account，能確保它的權限不會太大，影響到其他部分的運作。

2. 你是否在 GCP 中運作程式？

因為 GCP 有特殊的驗證機制，可以直接使用內建的身份驗證，不一定真的要用 Service Account。

・是，往問題 3，確認是否使用容器服務，如果是，遇有其他方法可以使用。

・否，往問題 5，程式可能在本機或其他雲端的外部環境，可能真的要用 Service Account。

3. 是否在 GKE 或 Anthos 中執行容器 (Container) 應用程式？

GKE (Google Kubernetes Engine) 是 GCP 的容器管理服務，它把原生的 Kubernetes 直接做在 GCP 上，底層交由 GCP 直接來管理維護，並做出各種加值應用，比原生的 Kubernetes 更為方便強大。Anthos 則是讓地端也能夠執行 GKE。

・是，使用 Workload Identity Federation for GKE，這是 GKE 專門的身份驗證機制，比 Service Account 更安全。

・否，直接使用 Service Account。

4. 你的情境是否真的需要 Service Account？

它是問你是否需要在所有環境中統一驗證的方式，需要特殊的權限組合，或是自動化的操作。

・是：使用使用者憑證 (User Credentials) 模擬 (Impersonate) Service Account，因為這個動作必須要先做使用者身份驗證，事後可以追蹤到是誰在使用，而且它會產生短期憑證，會自動過期，比較安全。詳細內容可以參考這份文件。

・否：使用使用者憑證，就是使用者本人親自驗證。

5. 你的工作負載 (Workload；就是你在運作的程式) 是否支援 (Workload Identity Federation)？

它指的是 Workload Identity Federation 可以支援像是 AWS IAM 或 Azure AD 所提供的身份，這樣的話就不用額外建立和管理 Service Account 和金鑰，更安全也更方便。

・是：是：設定 Workload Identity Federation。

・否：建立 Service Account Key，已經沒有其他更好的方式了。

(五) 預設的 Service Account 

1. 為什麼會有預設的 Service Account？

你可能會發現，在 Cloud IAM 的畫面中，經常看到兩個預設的 Service Account： Compute Engine default service account 和 App Engine default service account。

這些 Service Account 是 GCP 自動創建的，主要用於特定服務的運行授權。當 Compute Engine VM 或 App Engine 應用程式運行時，GCP 會自動為它們提供一個安全的「內部身份驗證代碼 」(Identity Token)，這些代碼用來代表預設的 Service Account 進行身份驗證和授權。

2. 預設的 Service Account 的特點如下

・無需手動管理密鑰檔案：不需要產生、下載 Service Account 金鑰檔案。

・安全性更高：避免了因金鑰洩露導致的資安風險。

・簡化操作：應用程式可以直接使用 Google 提供的函式庫 (例如 Google Cloud SDK 或 Cloud Client Libraries) 進行授權，這些程式庫會自動檢測並使用預設的身份。

以下分述兩個預設的 Service Account：

(1) Compute Engine Default Service Account

Compute Engine Default Service Account 是當您在專案中啟用 Compute Engine API 時自動生成的 Service Account，它的格式會長這個樣子：

[project-number]-compute@developer.gserviceaccount.com

你可能會想，你什麼時候啟用這個 API？其實當你建立好一個新的專案，接著要準備建立你第一台虛擬機器時，它就會自動啟用 Compute Engine API 了。

由於虛擬機器在 GCP 裡面也可能要呼叫其他服務，所以這個 Service Account 會授權虛擬機器存取 GCP 資源，例如讀取 Cloud Storage 中的資料或與 Cloud SQL 進行互動。

預設情況下，此 Service Account 通常具有 Editor 角色 (Role)，即允許對專案中的所有資源進行讀寫操作。然而，這種設置在安全性上存在潛在風險，詳細內容可以參考這份文件。

你可能會很緊張，擔心如果機器被駭客入侵，那駭客不就拿到 Editor 角色的權限了？

其實當我們在建立機器時，雖然 GCP 預設使用 Compute Engine Default Service Account，但是它受到「存取權範圍」的控制。如果你當時切換到「針對各個 API 設定存取權」，可以看到它原始的設定如下圖：

它的預設設定包含：Storage 和 Service Management 的唯讀存取權、Stackdriver Logging 和 Monitoring 的寫入權限，以及 Service Control 的讀取/寫入權限。所以它的權限是比較小的，不用太過擔心。

假如你對這一點有充份了解，那就建議你以後建立虛擬機器時，不要使用 Compute Engine Default Service Account，而是用你自訂的 Service Account，然後採用最小權限原則，根據 VM 的具體需求調整其角色。

例如，只賦予存取必要資源的權限，而非整個 GCP 專案所有服務的讀寫權限。還要注意要設定 Logs Writer 和Monitoring Metric Writer，這樣虛擬機器才能夠把 Log 和效能指標寫入 GCP 喔！

(2) App Engine Default Service Account

這是當您啟用 App Engine 應用程式時，GCP 自動創建的 Service Account，它的格式會長這個樣子：

[project-id]@appspot.gserviceaccount.com

它會授權 App Engine 的應用程式存取 GCP 資源，例如呼叫其他 GCP 服務的 API 或存取資料庫。

這個 Service Account 也有 Editor 角色，允許應用程式對專案內的資源進行各種讀寫操作。它和 Compute Engine default service account 一樣，預設權限過高可能導致安全性問題。

建議你手動把它的 Editor 角色改成更小權限的角色，等到它存取其他服務，卡住的時候再逐步開放也不遲。

如果你的機構 (Organization) 是在 2024 年 5 月 3 日以後建立的，它有一個機構政策「停用自動為預設服務帳戶授予 IAM 的功能」，是預設會強制執行的，那就不用擔心。(注意你要切換到機構角度，不是專案角度)

像我是的機構是之前就建立的，該政策並沒有強制執行，就請務必透過「管理政策」來改成「強制執行」。

(五) Service Account 注意事項

在 GCP 官方文件提供的 Service Account 注意事項非常多，這裡整理幾個最簡單也最重要的要點給大家：

1. 將 Service Account 視為資源管理

因為它的使用方式，跟一般的使用者帳號差很多，所以要定期觀查每個 Service Account 的使用情形，如果有程式不再運作，就要跟著停用對應的 Service Account 和金鑰。

2. 建立單一用途的 Service Account

遵守最小權限原則，Service Account 只做一件事，使用最小剛好用到的權限，不要使用預設的 Service Account。

3. 建立並遵守命名原則

讓大家一看就知道 Service Account 用在什麼地方，甚至在說明欄位記錄聯絡人和文件連結，以後如果要異動，能夠找到對應的負責人員聯絡，避免誤刪造成系統無法運作。

4. 識別並停用未使用的 Service Account

你可以使用 Activity Analyzer 檢查使用情況，查看最近 Servcie Account 和金鑰的驗證記錄，具體操作可以查看這份文件。

5. 在刪除前先停用

先停用一段時間再決定是否刪除 Service Account，或先刪除金鑰，觀查是否有影響到某個程式的運作，避免太快誤刪造成系統維護的麻煩。

6. 不要用預設的 Service Account

如上述所談，權限太大了。虛擬機器也不要用預設的 Service Account，盡量用專屬的 Service Account 配上專屬的角色。

7. 不要使用網域授權 (Domain-wide Delegation)

這個權限太大了，會讓 Service Account 模擬組織中的任何使用者，也容易被駭客拿來破壞。或是必須設定權限到期日，不要讓它的權限一直存在。 

8. 不要讓任何人可以直接存取 Service Account

如果一個使用者可以存取 Service Account，他就有可能用 Service Account 的權限做更多事情，甚至利用 Servcie Account 的權限 (像是 iam.serviceAccounts.setIamPolicy)，再間接取得更多權限。

9. 在沒有其他選擇時才使用 Service Account 金鑰

使用金鑰做所份驗證時，你沒有辦法追蹤誰使用了金鑰。此外也不要把金鑰檔案儲存在公開的程式碼儲存庫 (如 GitHub)。還有定期輪替金鑰，防止過期或洩露帶來的風險。  

10. 善用稽核記錄 (Audit Logs)

某些 GCP 服務 (例如 Compute Engine) 在Audit Logs 中會包含 serviceAccountDelegationInfo 欄位，這個欄位會顯示Service Account 是否被模擬使用，以及是誰在模擬這個 Service Account。

但不是所有服務都會記錄模擬的詳細資訊，需要額外啟用某些 API 的資料存取記錄，否則可能會遺漏重要的追蹤資訊。因此還要再啟用 Data Access Logs： 

(1) Identity and Access Management (IAM) API，能夠追蹤 Service Account 的詳細使用情況。

(2) Security Token Service API，會記錄 Token 的請求和發放，追蹤身份驗證的過程。

還有很多更細節的注意事情，有需要再參考這份文件。

五、結論

你會發現，本文前半部在開始介紹 IAM 還蠻簡單的，後面隨著牽涉到的範圍越廣也越深。因為整個 GCP 環境內的所有動作，沒有一個和權限無關，就算是 GCP 本身例行性的維護和運作，雖然沒有經過你的操作，你也都能夠查到相關的記錄和使用的權限，而不會直接隱藏不讓你知道。

所以 Cloud IAM 就是 GCP 運作的底層邏輯之一，如果這部分能夠充分了解，對你以後操作 GCP 和故障排除時會很有幫助，也能夠確保整個環境的資訊安全，避免內部人員越權或駭客入侵造成嚴重的後果。

本文同時刊登在思想科技官方網站：

【東東老師 X 思想科技】Google Cloud IAM 的角色與權限控管介紹

【東東老師Ｘ思想科技】Google Cloud IAM Service Account 基本介紹和設定