GCP 環境設定：建立 Project、設定 IAM 與使用 Cloud Shell

第一次打開 Google Cloud Console，最容易卡住的通常不是技術，而是不知道現在選的是哪個 Project、費用算到哪裡，或手上的帳號到底有什麼權限。

這篇會把這三件事整理好。先建立或選取獲授權的 Project，再用 Cloud Shell 核對身分與範圍、保存設定；最後可建立、查詢並刪除一個練習服務帳戶。這個帳戶不附掛工作負載、不授予資料角色，也不下載金鑰。

開始前準備好：

• 可登入 Google Cloud 的 Google 身分（個人或組織提供）
• 可建立或已獲授權使用的練習 Project；公司／教學環境先向管理員確認範圍
• 若自行申請免費試用，準備支援的付款方式，依所在地與官方要求驗證
• 一個現代瀏覽器

開始前，先把帳號與費用說清楚

建立 Project、啟用計費與申請試用要分開看

建立專案需要相應權限與剩餘配額，不是先提供個人信用卡才能做的操作。若已有公司或課程提供的練習專案，先確認你能操作的資源與計費安排，不要另外申請個人試用來繞過組織限制。

建立 Project 不表示計費已啟用：需要計費的服務，還要將專案連結至有效的 Cloud Billing 帳戶。申請 Free Trial 則是另一條取得試用計費帳戶的流程。可先查閱建立專案所需權限與確認專案計費狀態。

免費試用會不會自動扣款？

Google Cloud 的免費試用不會在到期時自動升級成付費帳戶。你必須主動升級，平台才會依用量收費。申請時仍會要求付款方式，主要是驗證身分與防止免費額度被濫用。

免費方案大致分成兩種：

1. 90 天免費試用：$300 USD 額度，限符合試用條件的服務與用途；實作前查閱官方適用限制
2. Free Tier：部分產品每月有固定的免費用量，和試用額度分開計算

額度用完或期限到了，未升級的試用計費帳戶會關閉，關聯資源停止。若主動升級成付費帳戶，應同時設定費用監控與清理方式；本篇使用的僅提醒預算只會通知，不會自動關閉資源。

先記住

免費試用不會自行轉成付費帳戶。升級後，不在剩餘有效額度或 Free Tier 範圍內的用量可能收費。做完練習後要主動清理，不把本篇僅提醒預算當成費用上限。

stateDiagram-v2
  [*] --> Trial: 完成身分與付款方式驗證
  Trial: 90 天或 300 美元額度內
  Trial --> Trial: 建立資源並消耗額度
  Trial --> Expired: 期限到或額度用完
  Trial --> Paid: 使用者主動升級
  Expired: 試用資源停止，帳戶不自動扣款
  Expired --> Paid: 使用者主動升級並重新啟用
  Paid: 依實際用量計費
  Paid --> Guarded: 設定預算、告警與資源清理習慣
  Guarded --> Guarded: 持續監控費用與用量

一開始就把練習資源放進獨立 Project，有兩個好處：權限和帳單比較容易追，也不會和日後的正式資源混在一起。Cloud Shell 則讓你不用先處理本機安裝問題，可以直接練習 gcloud 指令。

申請帳號與免費試用

以下步驟供自行申請試用者使用。若已獲授權使用現有練習專案，可略過申請流程，前往建立或確認練習用 Project；需要使用計費服務時，仍須確認該專案已有有效的計費連結。

步驟 1：前往 GCP 免費試用頁面

1. 開啟瀏覽器，前往 https://cloud.google.com/free
2. 確保你已登入 Google 帳號；組織提供的身分應先確認公司或課程的使用規範
3. 點擊 「Get started for free」 按鈕

步驟 2：選擇國家/地區與同意條款

GCP 會詢問：

• 所在國家/地區（選擇「台灣」或實際所在地）
• 是否同意服務條款

選擇的國家或地區會影響可用服務、付款資料與定價，請照實際所在地填寫。

勾選「我同意 Google Cloud 服務條款」後，點擊 「繼續」。

步驟 3：驗證信用卡資訊

付款方式用來驗證帳戶並降低免費額度被濫用的情況。驗證時，銀行端可能會出現一筆小額授權保留；它不是正式消費，解除時間依發卡銀行而定。

依畫面填寫：

1. 信用卡號碼
2. 到期日期
3. 依卡片及表單要求填寫安全碼（位置與位數依卡種而異）
4. 帳單地址

完成後，點擊 「開始免費試用」。

步驟 4：確認試用啟用

成功後，你會看到：

• GCP Console 主畫面
• 右上角顯示「免費試用中」
• 剩餘試用額度：$300 USD

看到這些資訊，就表示試用已啟用。

常見問題排解

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

認識 GCP 資源層級：Organization / Folder / Project

帳號準備好後，先別急著建立 VM。花幾分鐘看懂資源放在哪裡，之後切換專案、查帳單和設定權限時會少很多困惑。

GCP 資源層級架構

GCP 用樹狀結構整理資源：

Organization (組織)
    ↓
Folder (資料夾) - 可選
    ↓
Project (專案) - 必要
    ↓
Resources (資源：VM, Database, Storage...)

從最上層往下看：

Organization（組織）

Organization（組織）是資源階層的最上層，通常對應一家公司。公司可以在這裡集中管理旗下 Project 的政策與權限。

個人 Gmail 帳號通常看不到 Organization，這是正常的。自己練習時直接建立 Project 就可以，不需要為了補齊這一層另外設定 Workspace。

個人帳號看不到 Organization？

沒有漏設定。Organization 主要用在企業環境，個人帳號可以直接從 Project 開始。

Folder（資料夾）

Folder（資料夾）是 Organization 和 Project 中間的可選分組。公司常用部門、環境或產品線分類，也可以建立多層 Folder：

Organization: example-corp
├── Folder: 研發部
│   ├── Project: rd-dev
│   └── Project: rd-prod
└── Folder: 行銷部
    └── Project: marketing-analytics

個人練習通常用不到 Folder，知道它會影響權限繼承即可。

Project（專案）

Project（專案）是日常操作最常碰到的層級。VM、Storage bucket、資料庫等資源都會放在某個 Project 裡；API 啟用狀態、部分權限和費用也以 Project 為主要邊界。

每個 Project 都有三個識別欄位：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

其中最常用的是 Project ID。gcloud 指令和 API 經常要指定它，而且建立後不能修改。命名時可以把應用和環境放進去，例如 myapp-dev、myapp-prod，看到名稱就知道用途。

實務上也常把開發、測試和正式環境拆成不同 Project，讓權限、API 與費用比較容易分開管理。

Resources（資源）

Resources（資源）就是實際建立的 VM、Storage bucket 或 Cloud SQL 執行個體。資源會隸屬某個 Project；跨 Project 存取並非完全不行，但要另外設定網路與 IAM，不能假設建立後就彼此互通。

IAM 政策的繼承機制

IAM 權限可以從上層往下繼承：

Organization 層級的權限
    ↓ 繼承
Folder 層級的權限
    ↓ 繼承
Project 層級的權限
    ↓ 繼承
Resource 層級的權限

例如在 Organization 層級授予的 Allow 角色，會由下層繼承適用的權限。實際請求仍要評估角色包含的 permission、授權條件與相關 Deny／Principal Access Boundary 等限制，不能只看到 Viewer 就推論所有資料均可讀。範圍越高，影響越廣；應選支援且足夠完成任務的最小資源範圍。

建立練習用 Project

若管理員已提供專案，直接選取並確認 Project ID，不必重建。自行建立時，需有 resourcemanager.projects.create 權限（例如 Project Creator 角色），並有可用配額。專案數量不是固定 25 個；以目前帳號／組織的配額為準，參考官方配額說明。

1. 在 GCP Console 頂端，點擊「Select a project」下拉選單
2. 點擊 「NEW PROJECT」
3. 填寫資訊：
   • Project name: my-first-gcp-project
   • Project ID: （系統會自動產生，你也可以自訂）
   • Organization / Folder: 選擇獲授權的上層資源；若有「No organization」選項，個人練習可依情況使用
4. 點擊 「CREATE」

建立或選取完成後，回到 Console 頂端確認目前選到的是這個 Project。後面執行指令前也會再次檢查，避免把資源建到別的地方。

建立成功，但無法選擇計費帳戶？

建立專案的權限與使用計費帳戶的權限分開管理。不要因為能建立 Project 就假設能連結任何帳戶；請向管理員確認授權的計費帳戶及所需角色，不要為了繞過權限問題改綁個人帳戶。

確認計費與預算範圍

1. 在 Console 選好練習 Project，進入 Billing／帳單，核對實際連結的帳單帳戶及啟用狀態。名稱相似時，使用 Project ID 與帳單帳戶 ID 區分。
2. 沒有連結或帳戶已停用時，需要計費的後續 Lab 先暫停；請有權限的人員處理，不把「有試用額度」當成每個 Project 都已可用。
3. 在 Budgets & alerts／預算與快訊，由有權限的人設定本次 Project 範圍的僅提醒預算（alerts-only budget）。核對幣別、期間、金額、是否計入抵免、通知門檻及收件對象；不要把整個共用帳單帳戶當成本次範圍。
4. 記下誰接收通知、何時檢查費用、練習後清理哪些資源。使用者不一定會收到預設寄給管理員的信，通知也可能延遲。

僅提醒預算不限制支出；官方另有適用部分服務的支出上限預算，應分清類型與涵蓋範圍，見官方預算說明。沒有帳單查看權限時，記為「待管理員確認」，不能判斷為未計費或零費用。稍後也會用 CLI 交叉核對。

IAM：決定誰能做什麼

Project 建好之後，下一個問題是誰能查看或修改裡面的資源。這由 IAM（Identity and Access Management）負責。

IAM 是什麼？

IAM 管的是「誰」可以對「哪些資源」做「什麼操作」。

可以把它想成公司的門禁：員工與訪客是不同身分，辦公室與機房是不同範圍，而進門、使用設備或修改設定則是不同權限。IAM 只是把這套關係套到雲端資源上。

一次授權包含三個部分

在 GCP 裡，一次授權會把三件事連在一起：

在某個 Resource 的 Allow policy 中：
Binding = Role + Members（主體清單）+ 可選 Condition

也就是「誰能在哪個範圍做什麼」。一份政策可有多個 Binding；這是入門的 Allow 模型，完整請求還需評估其他限制。

1. Principal（主體）— 誰要存取？

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

登入 Console 的 Google 帳號是一種 Principal；Service Account（服務帳戶）也是，只是它通常交給程式或工作負載使用，而不是讓人登入。文章後面會實際建立一個。

2. Role（角色）— 給什麼權限？

GCP 的角色分成三類：

Basic Roles（基本角色）

這三個角色範圍很廣：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

如果同事只需要管理 VM，直接給 Editor 會連其他服務的修改權限一起開出去。除非情境真的需要，否則應優先找範圍更小的角色。

Predefined Roles（預定義角色）

Google 為各項服務提供較細的角色，可以依工作內容選擇：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

預定義角色由 Google 維護，通常比 Basic Roles 更接近實際工作需求。選擇時仍要查看它包含哪些 permission，不能只看角色名稱猜用途。

Custom Roles（自訂角色）

如果預定義角色沒有符合需求，也可以自己組合 permission，例如做一個只能啟動與停止 VM、不能刪除 VM 的角色。自訂角色還要負責後續維護；學習階段先用預定義角色即可。

flowchart TB
  REQUEST["有人或工作負載<br/>需要存取 GCP"] --> ACTION["列出完成任務<br/>真正需要的操作"]
  ACTION --> PRINCIPAL{"Principal 是誰？"}
  PRINCIPAL -->|"多人共同職能"| GROUP["優先使用<br/>Google Group"]
  PRINCIPAL -->|"應用程式或自動化"| SA["使用<br/>Service Account<br/>或工作負載身分"]
  PRINCIPAL -->|"單一人員的暫時需求"| USER["使用個人帳戶<br/>並設定檢查期限"]
  GROUP --> ROLE{"是否有涵蓋必要操作的<br/>Predefined Role？"}
  SA --> ROLE
  USER --> ROLE
  ROLE -->|"有"| PREDEFINED["選最小的<br/>Predefined Role"]
  ROLE -->|"沒有，且需求長期明確"| CUSTOM["建立並維護<br/>Custom Role"]
  ROLE -->|"只想省事"| AVOID["不要直接給<br/>Owner 或 Editor<br/>回頭拆解必要權限"]
  AVOID --> ACTION
  PREDEFINED --> SCOPE{"最小可行授權範圍在哪裡？"}
  CUSTOM --> SCOPE
  SCOPE --> BIND["在 Resource、<br/>Project、Folder<br/>或 Organization<br/>的適當層級綁定"]
  BIND --> REVIEW["測試允許與拒絕情境<br/>設定定期檢查與撤銷條件"]

3. Resource（資源）— 對哪些東西授權？

可以在不同層級授權：

• Organization 層級（影響所有資源）
• Folder 層級
• Project 層級
• 個別 Resource 層級（如單一 VM）

三個值得先養成的習慣

1. 最小權限原則 (Principle of Least Privilege)

不好的做法：

授予 alice@gmail.com 為 Project Owner
（她也有刪除整個專案的權限）

好的做法：

先列出 Alice 必須執行的 VM 操作與目標資源
再查角色的完整 permission，限制授權範圍
若只需查看 VM 設定，先評估 Compute Viewer，而非直接給管理角色

2. 使用群組而非個人帳號

不好的做法：

逐一授權給 alice@, bob@, charlie@
（新人加入要一個個加，離職也要一個個移除）

好的做法：

建立 Google Group "dev-team@"
授權給群組
（只需管理群組成員，IAM 設定不變）

3. 定期檢查不再使用的權限

IAM Recommender 可根據支援的使用資料提出權限調整建議；是否有建議及可用功能取決於資源、權限與服務支援：

1. 前往 GCP Console → IAM & Admin → IAM
2. 在主體清單找到「Security insights」欄，點開有「Recommendation available」圖示的項目
3. 核對依據、工作週期與影響，再決定是否變更；不能直接把未觀察到使用等同永遠不需要

範例建議：

「某項管理角色的已觀察使用範圍較小」是待評估訊號；應核對備援、月結與部署等低頻工作，再測試較小的角色。這是觀念示例，不是保證會出現的介面訊息。

練習：授予與移除查看權限

先推演，不需要邀請朋友或儲存真實授權。在 IAM & Admin → IAM 唯讀查看已獲准檢視的政策，分辨直接與繼承角色；沒有查看權限可先用下表練習。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

啟用 Cloud Shell 與基本操作

接下來用 Cloud Shell 執行指令。它是開在瀏覽器裡的 Linux 終端機，適合用來做短時間的管理與練習。

Cloud Shell 是什麼？

常用工具如 gcloud、Git 與文字編輯器已備妥；第一次讓工具呼叫 API 時，可能需要在 Cloud Shell 提示中按 Authorize。這只是讓工具使用目前登入憑證，不會增加 IAM 權限。Terraform CLI 自 2026 年 6 月 20 日起不再預裝，見官方版本紀錄。Cloud Shell 另外提供網頁版編輯器與 5 GB 的家目錄空間。

這樣可以先避開 Windows、macOS 與 Linux 安裝方式不同的問題。不過 Cloud Shell 是臨時管理環境，不適合拿來長期執行服務，重要檔案也不該只存一份在裡面。

啟用 Cloud Shell

1. 在 GCP Console 右上角，點擊 「Activate Cloud Shell」 圖示（看起來像 >_）
2. 等待幾秒鐘，終端視窗會從底部彈出
3. 看到提示字元 username@cloudshell:~$，就可以開始輸入指令

Console 介面與快捷鍵偶爾會調整；找不到時，直接在右上角尋找 >_ 圖示即可。

Cloud Shell 基本操作

1. 確認當前 Project

先在 Console 選好練習專案，再比較終端目前的帳號、Project 與模擬設定：

gcloud config get-value account
gcloud config get-value project
gcloud config get-value auth/impersonate_service_account

Cloud Shell 啟動時會接收 Console 的 Project，但每次操作仍應重新核對，不假設不同分頁或先前設定已同步。本篇使用一般 Google／Workspace 使用者，且沒有預設模擬身分；若身分不是預期值，先切回獲授權的設定，不用重新登入來掩蓋原因。

將第一行換成 Console 顯示的 Project ID，在 Cloud Shell Bash 一次執行整段。只查專案並建立私人本機目錄，沒有建立雲端資源或改寫 gcloud 預設設定：

export SETUP_PROJECT='YOUR_PROJECT_ID'
export SETUP_CONTEXT="$HOME/cloudon-setup-labs/setup02-$(date -u +%Y%m%d%H%M%S)-$RANDOM/context.env"
(
  set -eu
  umask 077
  case "$SETUP_PROJECT" in
    ''|'YOUR_PROJECT_ID'|'(unset)') echo '請先填入自己的 Project ID。' >&2; exit 1 ;;
  esac
  SETUP_ACCOUNT="$(gcloud config get-value account)"
  case "$SETUP_ACCOUNT" in
    ''|'(unset)'|*.gserviceaccount.com) echo '請先核對獲授權的一般使用者帳號。' >&2; exit 1 ;;
    *@*) ;;
    *) echo '本篇使用一般 Google／Workspace 使用者，其他身分請另行核對。' >&2; exit 1 ;;
  esac
  SETUP_IMPERSONATION="$(gcloud config get-value auth/impersonate_service_account)"
  case "$SETUP_IMPERSONATION" in
    ''|'(unset)') ;;
    *) echo '目前有預設模擬身分，請先恢復核准的使用者設定。' >&2; exit 1 ;;
  esac
  gcloud projects describe "$SETUP_PROJECT" --account="$SETUP_ACCOUNT" \
    --format='yaml(projectId,name,projectNumber,lifecycleState)'
  SETUP_STATE="$(gcloud projects describe "$SETUP_PROJECT" --account="$SETUP_ACCOUNT" \
    --format='value(lifecycleState)')"
  if [ "$SETUP_STATE" != 'ACTIVE' ]; then
    echo '專案不是 ACTIVE，請先確認狀態。' >&2
    exit 1
  fi
  SETUP_DIR="$(dirname "$SETUP_CONTEXT")"
  SETUP_SA_ID="$(basename "$SETUP_DIR")"
  SETUP_SA="$SETUP_SA_ID@$SETUP_PROJECT.iam.gserviceaccount.com"
  mkdir -p "$SETUP_DIR"
  for field in SETUP_PROJECT SETUP_ACCOUNT SETUP_DIR SETUP_SA_ID SETUP_SA; do
    printf 'export %s=%q\n' "$field" "${!field}"
  done > "$SETUP_CONTEXT"
  cat >> "$SETUP_CONTEXT" <<'SETUP_CHECKS'
umask 077
SETUP_IMPERSONATION="$(gcloud config get-value auth/impersonate_service_account)"
case "$SETUP_IMPERSONATION" in
  ''|'(unset)') ;;
  *) echo '預設模擬身分已變更，請先恢復核准設定。' >&2; return 1 ;;
esac
SETUP_CHECKS
  printf 'Project=%s\nAccount=%s\n本次設定檔=%s\n' \
    "$SETUP_PROJECT" "$SETUP_ACCOUNT" "$SETUP_CONTEXT"
)

核對專案輸出為預期 ID，且 lifecycleState 為 ACTIVE；不是 ACTIVE 就先停止。記下完整設定路徑。後續每段都載入同一設定，雲端操作明確帶入保存的 --project 與 --account，避免依賴目前 CLI 預設值。設定檔沒有權杖，但也不應提交到版本庫。

恢復本次 Cloud Shell 設定

ls -lt "$HOME/cloudon-setup-labs"/*/context.env
export SETUP_CONTEXT="$HOME/cloudon-setup-labs/替換成本次目錄/context.env"
(
  set -eu
  source "${SETUP_CONTEXT:?請先指定原本的設定檔路徑}"
  printf 'Project=%s\nAccount=%s\nSA=%s\n' "$SETUP_PROJECT" "$SETUP_ACCOUNT" "$SETUP_SA"
)

在建立 VM 前交叉核對

使用保存的 Project 與帳號查詢，不變更計費、啟用 API 或建立 VM：

(
  set -eu
  source "${SETUP_CONTEXT:?請先完成準備或恢復設定檔}"
  gcloud billing projects describe "$SETUP_PROJECT" \
    --project="$SETUP_PROJECT" --account="$SETUP_ACCOUNT" \
    --format='yaml(projectId,billingAccountName,billingEnabled)'
)

只有成功輸出的 billingEnabled: true 且帳單帳戶符合核准範圍，才完成本項核對。false 表示未啟用；非零狀態、沒有查看權限或無法連線則是「未能確認」，都不能當成可開始計費 Lab 的證據。

接著查 Compute Engine API：

(
  set -eu
  source "${SETUP_CONTEXT:?請先完成準備或恢復設定檔}"
  SETUP_COMPUTE_API="$(gcloud services list --enabled \
    --project="$SETUP_PROJECT" --account="$SETUP_ACCOUNT" \
    --filter='config.name=compute.googleapis.com' --format='value(config.name)')"
  if [ "$SETUP_COMPUTE_API" = 'compute.googleapis.com' ]; then
    printf 'Compute Engine API 已啟用；仍需核對 VM、網路、SSH 權限與配額。\n'
  elif [ -z "$SETUP_COMPUTE_API" ]; then
    printf 'Compute Engine API 尚未啟用；開始 VM Lab 時由有權限者依範圍啟用。\n'
  else
    echo 'API 查詢結果不符，請先核對。' >&2
    exit 1
  fi
)

查詢成功的空結果與 API 查詢失敗不同。登入、Project 存在、計費啟用、API 啟用、操作權限與可用配額是不同條件；本篇查詢不會一次證明全部就緒。遇到權限或組織政策限制，記下動作、Project 與錯誤碼，交由管理員核對，不自行授予 Owner／Editor。

2. 檢查已安裝的工具

# 檢查 gcloud 版本
gcloud version

# 檢查 kubectl 版本
kubectl version --client

# 檢查 Python 版本
python3 --version

# 檢查 Node.js 版本
node --version

這幾個工具的版本會隨 Cloud Shell 映像更新，輸出不一定和文章撰寫時相同。

3. 使用內建程式碼編輯器

Cloud Shell 也提供網頁版程式碼編輯器：

開啟編輯器：

1. 點擊右上角的 「Open Editor」 圖示（鉛筆形狀）
2. 從編輯器開啟本次目錄內的 hello.sh。也可以先執行下方區塊，建立並測試自己的非敏感腳本：

(
  set -eu
  source "${SETUP_CONTEXT:?請先完成準備或恢復設定檔}"
  printf "printf 'Hello from Cloud Shell!\\n'\n" > "$SETUP_DIR/hello.sh"
  bash "$SETUP_DIR/hello.sh"
  cloudshell edit "$SETUP_DIR/hello.sh"
)

預期輸出：

Hello from Cloud Shell!

4. 保存檔案

Cloud Shell 的 $HOME 目錄（/home/your_username）會跨工作階段保留，總容量 5 GB。不過，若長時間沒有使用 Cloud Shell，家目錄可能會被刪除。程式碼應放進版本庫，重要成果要另存到耐久儲存，敏感資料則交給 Secret Manager 之類的受管服務。

測試：

(
  set -eu
  source "${SETUP_CONTEXT:?請先完成準備或恢復設定檔}"
  printf 'CloudOn setup persistence check\n' > "$SETUP_DIR/persistent-file.txt"
  printf '已建立在本次目錄：%s\n' "$SETUP_DIR"
)

關閉並重新開啟 Cloud Shell，依恢復設定找回原路徑，再讀取：

(
  set -eu
  source "${SETUP_CONTEXT:?請先恢復原本的設定檔}"
  cat "$SETUP_DIR/persistent-file.txt"
)

看到 CloudOn setup persistence check，只證明本次檔案跨工作階段保留，不等於永久備份。若使用 ephemeral 模式，不能期待檔案留下來；不要為了完成檢核而重新建立同名檔案。

/tmp 只適合暫存，VM 重啟後內容會被清除。

flowchart TB
  FILE["Cloud Shell 產生<br/>或編輯的檔案"] --> TEMP{"只在目前工作階段暫用？"}
  TEMP -->|"是"| TMP["放在 /tmp<br/>接受 VM 重啟後清除"]
  TEMP -->|"否"| SECRET{"是否包含密碼、<br/>私鑰、Token<br/>或其他敏感資料？"}
  SECRET -->|"是"| MANAGED["不要只留在<br/>Cloud Shell<br/>改用<br/>Secret Manager<br/>或短期身分"]
  SECRET -->|"否"| SOURCE{"是否為程式碼、<br/>IaC 或文件？"}
  SOURCE -->|"是"| GIT["提交到適當的<br/>私人版本庫<br/>以版本紀錄作為<br/>主要保存來源"]
  SOURCE -->|"否"| HOME["可暫放 HOME<br/>的 5GB 空間"]
  HOME --> INACTIVE{"能接受連續 120 天未使用<br/>可能被刪除且無法復原？"}
  INACTIVE -->|"否"| DURABLE["同步到<br/>Cloud Storage<br/>或其他耐久儲存"]
  INACTIVE -->|"是"| KEEP["保留於 HOME，<br/>並定期檢查"]

5. 網頁預覽功能（Web Preview）

Cloud Shell 透過 HTTPS 代理預覽自己的開發伺服器；官方說明列出 2000–65000 的可用連接埠，代理限制目前使用者存取。這不是部署公開網站，也不會建立本篇 Project 裡的 VM。

範例：啟動一個簡單的 HTTP 伺服器：

(
  set -eu
  source "${SETUP_CONTEXT:?請先完成準備或恢復設定檔}"
  mkdir -p "$SETUP_DIR/preview"
  printf '<!doctype html><meta charset="utf-8"><h1>CloudOn Web Preview</h1>\n' \
    > "$SETUP_DIR/preview/index.html"
  exec python3 -m http.server 8080 --bind 127.0.0.1 --directory "$SETUP_DIR/preview"
)

然後：

1. 點擊 Cloud Shell 上方的 「Web Preview」 圖示
2. 選擇 「Preview on port 8080」
3. 新分頁會開啟並顯示網頁

應看到 CloudOn Web Preview，不是目錄清單。只把可公開的示範檔案放進 preview；設定檔與其他學習資料放在外層，不能把家目錄或含憑證的目錄拿來提供 HTTP 服務，也不要加入連到其他私人檔案的符號連結。Python 的簡易伺服器僅供練習，詳見官方 http.server 說明。

回到原終端按 Ctrl+C 停止，等提示字元回來，再確認重新整理預覽已無法取得這個頁面。只關閉預覽分頁不會停止伺服器；8080 已被占用時，先確認是否是自己的練習程序，不用廣泛 kill 指令停止其他工作。

常見用途包括：

• 測試前端網頁
• 預覽 API 文件
• 執行開發伺服器（如 React, Vue, Flask）

Cloud Shell 限制

Cloud Shell 有工作階段與資源限制，不要把它當成正式 VM：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

長時間執行或需要穩定效能的工作，應該改用正式 VM 或對應的受管服務。Cloud Shell 比較適合下管理指令、修改設定和跑短時間的 Lab。

配額、儲存與工作階段限制請查官方 Cloud Shell 限制。一般模式保留的是家目錄，不是整台 VM；ephemeral 模式則沒有持久磁碟，不能套用同樣的檔案保留預期。

常用 gcloud 指令速查

本篇使用這幾類操作；資源查詢都要帶入明確 Project 與帳號，而非只看 CLI 的目前預設值：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

不確定參數時，可以加上 --help 查看說明：

gcloud compute instances create --help

練習：建立第一個服務帳戶

現在把 Project、IAM 與 Cloud Shell 串在一起，練習管理一個 Service Account（服務帳戶）。預留 10–15 分鐘，包含建立、查詢與清理；API 啟用、傳播與排錯另計。使用上方同一份設定，這個練習帳戶不需要留給下一篇 VM 使用。

本節需要 iam.serviceAccounts.create、iam.serviceAccounts.get、iam.serviceAccounts.list 與 iam.serviceAccounts.delete；若 IAM API 尚未啟用，還需 serviceusage.services.enable。建立者角色不一定包含刪除權限，開始前應連清理權限一起確認，參考官方建立指南與刪除指南。沒有權限或組織政策禁止時，保留未完成項目，不自行加管理角色。

什麼是服務帳戶？

服務帳戶通常代表程式或工作負載。人會用自己的 Google 帳號登入 Console；程式則透過服務帳戶取得呼叫 GCP API 所需的身分與權限。

例如：

• 讓你的 Python 腳本自動把檔案上傳到 Cloud Storage
• 讓 CI/CD（Continuous Integration / Continuous Delivery，自動測試與自動部署的流水線）把程式自動部署到 GCP
• 讓一台 VM 去存取其他 GCP 服務，而不用把你的個人帳密塞進去

flowchart TB
  CONTEXT["核對並保存<br/>Project、操作者、本次名稱"] --> CREATE["啟用 IAM API<br/>建立本次 SA"]
  CREATE --> READ["查詢同一 email 與 uniqueId<br/>辨認 SA 資源"]
  READ --> SCOPE["沒有資料工作負載<br/>不新增角色、不產生金鑰"]
  SCOPE --> DELETE["確認本次名稱後刪除<br/>保留 CLI 確認"]
  DELETE --> VERIFY["清單查詢成功且找不到本次 email<br/>才確認本次 SA 已清理"]
  CREATE -. "失敗或回應不明" .-> RECOVER["沿用設定查實際狀態<br/>不換名稱重建"]
  RECOVER --> DELETE
  SCOPE -. "要測實際資料存取" .-> IAM["另做 GCP-105 的<br/>授權、拒絕、撤回對照"]

步驟 1：建立服務帳戶

沿用上方設定，建立名稱含本次時間與隨機尾碼的 SA；ID 最長 28 字元，符合 6–30 字元限制。準備只做一次，中途失敗仍使用同一名稱查詢與清理：

(
  set -eu
  source "${SETUP_CONTEXT:?請先完成準備或恢復設定檔}"
  gcloud services enable iam.googleapis.com \
    --project="$SETUP_PROJECT" --account="$SETUP_ACCOUNT"
  gcloud iam service-accounts create "$SETUP_SA_ID" \
    --project="$SETUP_PROJECT" --account="$SETUP_ACCOUNT" \
    --description='Disposable CloudOn setup lifecycle practice' \
    --display-name="CloudOn Setup $SETUP_SA_ID"
)

預期輸出：

Created service account [setup02-本次時間-隨機尾碼].

步驟 2：授予權限

這個步驟先回答「為什麼需要授權」。本篇只有建立與刪除 SA 資源，沒有要存取的 Bucket 或應用程式，因此不新增 Project／Bucket 角色，也不授予操作者模擬權限。

步驟 3：列出服務帳戶

確認剛才建立的確切名稱，並記下系統分配的 uniqueId：

(
  set -eu
  source "${SETUP_CONTEXT:?請先完成準備或恢復設定檔}"
  gcloud iam service-accounts describe "$SETUP_SA" \
    --project="$SETUP_PROJECT" --account="$SETUP_ACCOUNT" \
    --format='yaml(email,uniqueId,disabled,displayName)'
  gcloud iam service-accounts list \
    --project="$SETUP_PROJECT" --account="$SETUP_ACCOUNT" \
    --filter="email=$SETUP_SA" --format='table(email,uniqueId,disabled)'
)

email 應與設定檔一致、disabled 應為 false，且兩次查詢的 uniqueId 相同。新建 SA 可能需要傳播時間才可讀取；失敗時先核對錯誤與原名稱，再等待重查，不能因清單暫時空白就重建另一個。

步驟 4：（可選）了解服務帳戶金鑰

本篇不建立或下載 JSON 金鑰。一般部署優先使用平台支援的工作負載身分、附加 SA 或 Workload Identity Federation；短期操作可依核准範圍模擬 SA，身分使用權限與資料權限仍分開管理。

步驟 5：清理資源

先確認未將本次 SA 接到工作負載或新增其他授權。核對此 email 與本次用途後，刪除唯一這個 SA；保留 gcloud 原生確認，不刪預設帳戶、整個 Project 或共用 API：

(
  set -eu
  source "${SETUP_CONTEXT:?請先完成準備或恢復設定檔}"
  gcloud iam service-accounts describe "$SETUP_SA" \
    --project="$SETUP_PROJECT" --account="$SETUP_ACCOUNT" \
    --format='yaml(email,uniqueId,displayName,description)'
  gcloud iam service-accounts delete "$SETUP_SA" \
    --project="$SETUP_PROJECT" --account="$SETUP_ACCOUNT"
)

若建立沒有成功或已刪除，describe／delete 可能失敗；某些 SA 操作即使名稱不存在也會回 PERMISSION_DENIED，因此不能只靠錯誤碼判斷不存在。使用同一專案的成功清單查詢交叉核對：

(
  set -eu
  source "${SETUP_CONTEXT:?請先完成準備或恢復設定檔}"
  SETUP_SA_REMAINING="$(gcloud iam service-accounts list \
    --project="$SETUP_PROJECT" --account="$SETUP_ACCOUNT" \
    --filter="email=$SETUP_SA" --format='value(email)')"
  if [ -n "$SETUP_SA_REMAINING" ]; then
    printf '本次 SA 仍在或刪除尚未傳播：%s\n' "$SETUP_SA_REMAINING" >&2
    exit 1
  fi
  printf '清單查詢成功，已找不到本次 SA：%s\n' "$SETUP_SA"
)

只有查詢成功且沒有這個 email，才確認本次 SA 已清理；權限、API 或網路錯誤都不算。若回應不明，等待後用原名稱重查。本篇沒有新增其他 Binding；若自行增加過授權，仍需逐一撤回，刪除 SA 不表示歷史政策立刻全部移除。

Cloud Shell 的示範檔案保留在本次私人目錄，並非計費服務資源。確認 8080 的預覽程序已用 Ctrl+C 停止；可從編輯器只移除本次 hello.sh、persistent-file.txt 與 preview/index.html。設定檔先保留到雲端清理確認完成，避免遺失查核依據。

做完後確認一次

進下一篇前，依自己實際完成的路線核對，不把閱讀或登入成功當成所有 Lab 都已就緒：

• 已登入正確身分，並確認練習專案的授權範圍
• 已建立或取得授權使用一個 Project，並記下正確 Project ID
• 能分辨建立專案、啟用計費與申請試用；需要計費服務時已成功核對有效計費連結及核准帳戶
• 已核對僅提醒預算的 Project 範圍、通知對象及清理方式，知道它不限制支出
• 講得出 IAM 的 Principal、Role、Resource 各是什麼
• 能找回同一次 Cloud Shell 設定，查詢使用明確 Project／帳號，知道 CLI 與 ADC 是兩條憑證路徑
• 若做網頁預覽，只提供專用目錄，且已停止前景伺服器
• 若做 SA 練習，已記下原 email／uniqueId，並以成功的清單查詢確認本次帳戶清理完成；若略過則標記未實作

如果其中一項還不確定，回到對應段落核對原設定，不盲目重建。下一篇另需確認 Compute Engine API、VM／網路／SSH 權限與配額，不必保留本篇練習 SA。

下一篇 GCP-103：第一台雲端主機——Compute Engine 從建立到監控 會建立 VM、用 SSH 連線、部署簡單網站，再設定防火牆與快照。

需要查指令或服務行為時，以 Google Cloud 官方文件 為準；想跟著 Lab 練習，可以使用 Google Skills（原 Google Cloud Skills Boost）。

關於本系列

這是 GCP 入門系列的第 2 篇。

系列導覽：

• ← 上一篇：GCP-101：先搞懂雲端，再決定要不要學 Google Cloud
• → 下一篇：GCP-103：建立第一台 Compute Engine VM

同階段文章：

• GCP-102：GCP 環境設定：建立 Project、設定 IAM 與使用 Cloud Shell（本篇）
• GCP-103：建立第一台 Compute Engine VM：連線、架站、備份與監控
• GCP-104：GCP 網路基礎：看懂 VPC、Subnet、防火牆與 IAP

系列目錄：查看課程列表

下一課：GCP-103：建立第一台 Compute Engine VM。