管理通道為什麼要收斂、它拆成哪幾層、各層有哪些與廠商無關的做法，在伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口。本篇是那套模型在 GCP 上的一種組合：

救援入口用 Serial Console，它不經過上面三層的設定，有自己的 IAM 權限與開關。

這個組合假設組織的身分提供者（identity provider，IdP）是 Google 帳號：IAP 與 OS Login 都依 Google 的 IAM 判斷。組織用的是 Microsoft Entra ID、Okta 這類其他 IdP 時，有兩條路。一條是讓 Cloud Identity 以 SAML 單一登入接那個 IdP、並由 IdP 把帳號同步進來，使用者在原本的 IdP 登入、拿到的是 Google 身分，本篇全部適用。另一條是通道授權改用能接那個 IdP 的代理服務，網路可達性跟著那個代理走（防火牆改放行它的位址段，或改用不開入站 port 的反向連線）；這時本篇依賴 Google 帳號的幾節——〈IAP 的 IAM 授權範圍：誰拿得到通道〉、〈SSH 金鑰在 GCP 上的管理位置：metadata 金鑰與 OS Login 的啟用條件〉的 OS Login 與組織政策的 compute.requireOsLogin、稽核紀錄裡 IAP 的 Data Access 紀錄——都不適用，Cloud NAT、移除外部 IP、Serial Console 與防火牆規則的收斂仍然適用。

另外四種環境要先調整做法再往下讀：

• 由 managed instance group（MIG）或 GKE 管理的 VM：tag、metadata、救援帳號與移除外部 IP 都要改在 instance template、node pool 設定或映像檔裡。逐台用 gcloud 修改，VM 在自動修復、升級或縮放時重建，修改就消失，tag 消失之後 IAP 規則也套不到新的 VM。這兩種環境的設定位置、救援改用重建的做法與 GKE 控制層的存取，見GCP 上由 MIG 與 GKE 管理的 VM 的管理存取。
• Shared VPC 的 service project：防火牆規則住在 host project，防火牆相關的指令要在 host project 執行；停用 default-allow-ssh 這類規則會同時影響其他 service project 的 VM。
• 用 Terraform 這類 IaC 管理的專案：每一個 gcloud 修改都要改寫成程式碼。只在 CLI 加的 tag、IAM 授權與 metadata，若所屬資源在程式碼裡被完整定義（例如 google_compute_instance 寫了 tags、用 google_project_iam_policy 管 IAM），下一次 apply 會把它拿掉；只在 CLI 刪掉的規則與外部 IP，下一次 apply 會建回來。用 CLI 停用舊規則做驗證的期間要暫停所有 apply。兩個方向的落差與過渡期的做法見兩套真相並存的過渡期操作。
• 新專案從零開始：沒有舊規則要移走，切換前的盤點與停用驗證可以跳過，直接建 IAP 規則、OS Login 與 Cloud NAT；建 VM 時加 --no-address 就不配外部 IP。2024 年 5 月 3 日之後建立的 Organization 會預設強制一組 Organization Policy，其中可能已經包含本篇〈組織層級的護欄：Organization Policy 與階層式防火牆〉提到的幾項；用 gcloud resource-manager org-policies list --organization=<org-id> 查組織層級設定了哪些（<org-id> 用 gcloud organizations list 查）。

預設網路自帶的防火牆規則

專案第一次啟用 Compute Engine API 時，GCP 會自動建一個叫 default 的 auto-mode VPC，並在上面預先建好四條入站規則。這四條規則的設計目標是讓第一次用 GCP 的人開完 VM 就連得上，所以來源範圍放得很寬。

GCP 的防火牆規則依 priority 數字由小到大評估。這四條的 priority 是 65534，只排在 VPC 隱含的「拒絕所有入站」規則（65535）前面，所以自己建立的規則（不指定時是 1000）都會比它們先被評估。它們也沒有指定 target tag（防火牆規則用來挑選作用對象的標記），作用對象是這個網路裡的每一台 VM。Oracle Cloud 與 AWS 預設網路的同類規則見 網路：subnet、私有 IP、公開 IP 與防火牆規則 的〈各家預設網路規則對 SSH 的開放〉。

只收掉 default-allow-ssh 會留下兩個暴露面。default-allow-rdp 讓每一台 Windows VM 的遠端桌面對整個網際網路開放，而 RDP 預設接受密碼登入。default-allow-internal 讓同一個網路裡的 VM 之間不受 port 限制，一台 VM 被入侵之後，攻擊者從那台機器能直接連到其他 VM 的資料庫 port 與管理 port，這種擴散方式叫橫向移動（lateral movement）。另外，這四條自動建立的規則預設沒有開啟 firewall rules logging，防火牆這一層不會留下被掃描或被連入的紀錄。管理 port 對外開放的風險與廠商無關，見伺服器管理通道的設計的〈對外開放管理 port 的實際風險〉。

CIS Google Cloud Platform Foundation Benchmark 的 3.1 條因此建議專案裡不保留 default 網路，改用自己規劃 subnet 的 custom-mode VPC。已經有服務跑在 default 網路上的專案，可以先收斂這四條規則，搬遷網路排進另一次變更；收斂 default-allow-internal 與 default-allow-icmp 的指令與實測結果在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈收斂 default-allow-internal 與 default-allow-icmp〉。

列出專案目前在 default 網路上的規則，--format 讓 gcloud 把來源範圍與 target tag 兩欄加進輸出（預設表格沒有這兩欄）：

1# 列出 default 網路上的防火牆規則，含來源範圍、放行內容與 target tag
2gcloud compute firewall-rules list --filter="network:default" \
3  --format="table(name,priority,sourceRanges.list():label=SRC_RANGES,allowed[].map().firewall_rule().list():label=ALLOW,targetTags.list():label=TARGET_TAGS,disabled)"

輸出裡要看 SRC_RANGES 欄是 0.0.0.0/0 的列，以及 TARGET_TAGS 欄是空白的列——空白代表規則套用到整個網路的每一台 VM。這兩條規則要換掉、不能直接刪：刪除的當下，管理員自己的 SSH 與 RDP 連線會一起中斷，理由見〈切換到 IAP 的順序〉。從 Security Command Center 的 OPEN_SSH_PORT 或 OPEN_RDP_PORT finding 進來的，finding 裡寫著被標記的那條規則的資源名稱，以那個名稱替換指令裡的 default-allow-ssh；網路不是 default 時，把 --filter 裡的網路名稱一起換掉。

IAP TCP forwarding 的連線路徑與來源範圍

IAP TCP forwarding 是 GCP 的身分感知代理：管理員的 gcloud 先用 HTTPS 連到 Google 的 IAP 端點，IAP 檢查這個 Google 帳號有沒有開通道的 IAM 權限，通過之後由 IAP 從 35.235.240.0/20 這段位址連到 VM 的內部 IP 與指定 port，再把兩端的位元組來回轉送。

一條連線因此由兩個元件各檢查一次，分別對應通道授權與主機登入驗證：

IAP 只決定是否允許開通道，開了通道之後登入 VM 仍然要過 VM 自己的認證，所以兩者要分開設定、分開稽核：IAM 給得太寬，sshd 就暴露給不該碰這台 VM 的成員；VM 的金鑰管理鬆散，拿到通道的人就能用別人留下的金鑰登入。

35.235.240.0/20 是 Google 文件公開的 IAP TCP forwarding 來源範圍，裡面包含 IAP 轉送時使用的全部位址。IPv6 的 VM 要另外放行 2600:2d00:1:7::/64；auto-mode 的 default 網路只有 IPv4 subnet，IPv6 的規則只在自建、開了 dual-stack subnet 的 custom-mode VPC 上用得到。這兩段位址是 Google 定義的規格值，每個專案都相同，可以直接寫進防火牆規則；Google 調整範圍時以 IAP TCP forwarding 文件為準。防火牆規則的關鍵是 --source-ranges=35.235.240.0/20 加上 --target-tags 限定作用的 VM、--rules 只開需要的 port，完整的建立指令與各引數在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈啟用 IAP API、開啟稽核紀錄並建立只放行 IAP 來源的防火牆規則〉。

設定完成之後，日常的連線指令是這幾條，<instance-name> 與 <zone> 用 gcloud compute instances list 查，第一欄是 VM 名稱、第二欄是 zone：

1# Linux：透過 IAP 通道 SSH 進 VM
2gcloud compute ssh <instance-name> --zone=<zone> --tunnel-through-iap
3
4# Linux：透過 IAP 通道傳檔
5gcloud compute scp <local-file> <instance-name>:<remote-path> --zone=<zone> --tunnel-through-iap
6
7# Windows：把 VM 的 3389 port 經 IAP 轉到本機的 13389，再用 RDP 用戶端連 localhost:13389
8gcloud compute start-iap-tunnel <windows-instance-name> 3389 --local-host-port=localhost:13389 --zone=<zone>

主控台上 VM 旁的 SSH 按鈕（SSH-in-browser）不是這幾條指令：官方〈Connect to Linux VMs using IAP〉寫明它只在 VM 沒有外部 IP 時才走 IAP，VM 還帶外部 IP 時它連的是外部 IP，舊規則停用之後就連不上。本機的 port 用 3389 以外的號碼（這裡是 13389），管理員自己的 Windows 電腦開著遠端桌面時，本機的 3389 已經被占用。Ansible 這類用一般 ssh 連線的工具，在 ssh 設定裡用 ProxyCommand 讓 gcloud 開通道：

1# ~/.ssh/config：<vm-name> 寫 VM 名稱，ssh 連線時代入 %h
2Host <vm-name>
3  ProxyCommand gcloud compute start-iap-tunnel %h 22 --listen-on-stdin --zone=<zone> --project=<project-id>
4  User <os-login-username>
5  IdentityFile <private-key-file>

--listen-on-stdin 讓 gcloud 把通道接到標準輸入輸出，ssh 就經由 IAP 連到 %h；這個旗標不出現在 gcloud compute start-iap-tunnel --help 的輸出裡，而功能存在。VM 啟用了 OS Login 時，一般 ssh 不會像 gcloud compute ssh 那樣自動把公鑰登錄到帳號的 OS Login profile，所以先以 Ansible 開通道所用的服務帳號（<ci-service-account-email>）的身分登錄一次：gcloud compute os-login ssh-keys add --key-file=<public-key-file> --impersonate-service-account=<ci-service-account-email>，<public-key-file> 是 <private-key-file> 對應的公鑰檔；<os-login-username> 用同樣加上 --impersonate-service-account 的 gcloud compute os-login describe-profile 輸出裡的 username。

IAP 通道的代價在傳輸速度：所有位元組都經過 Google 的轉送，傳大檔案比直連慢，大量傳檔適合改用 Cloud Storage 當中轉。

切換到 IAP 的順序

切換的順序由兩個事實決定。default-allow-ssh 的來源 0.0.0.0/0 本身就涵蓋 IAP 的位址段，所以舊規則還在的時候，經由 IAP 的連線成功，可能是舊規則放行的，證明不了新規則寫對了；驗證新規則因此要先停用舊規則。而停用舊規則的那一刻，從公開網際網路來的 SSH 與 RDP 都會被拒絕，包括管理員自己的連線與依賴這條規則的 CI、監控、廠商連線。所以：依賴舊規則的連線要先盤點出來並改走 IAP；救援入口（Serial Console 與本機救援帳號）要在停用之前準備好並實際登入過；新規則、tag 與 IAM 權限要在停用之前建好；停用之後確認新路徑可用，才刪除舊規則。與廠商無關的推導見伺服器管理通道的設計的〈切換管理通道時避免把自己鎖在外面〉。

這個順序裡有三件事的判斷落在 GCP 的機制上：

• 盤點靠 VM 上的登入紀錄，不只靠防火牆紀錄：全開規則的紀錄大部分是網際網路掃描程式的來源，CI 託管執行環境的 IP 每次不同，混在裡面認不出來；VM 上 sshd 紀錄的帳號與金鑰指紋才認得出是哪個人或哪個工具。
• 驗證用停用而不是刪除：停用的規則用 --no-disabled 一行恢復原樣，刪除之後要重建、重建時可能寫錯；防火牆規則透過 GCP 的 API 修改，SSH 連不上也改得回來。
• Serial Console 的權限收不窄：連 Serial Console 需要能修改這台 VM 的權限（例如 roles/compute.instanceAdmin.v1），而這個角色也是一般 VM 管理會用到的權限，所以光靠 IAM 收不窄救援入口；真正把它收窄的是組織政策 compute.disableSerialPortAccess（見〈組織層級的護欄：Organization Policy 與階層式防火牆〉）。組織強制了這條政策時，救援名單裡要有持有組織政策權限、能對專案解除它的人。

每一步的指令、實跑看到的輸出，以及每一步沒做或換一種做法時的結果，在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄：盤點在〈切換前的盤點：依賴舊規則的連線〉，救援入口在〈準備救援入口：Serial Console 與本機救援帳號〉，停用驗證在〈停用舊規則，用 IAP 驗證新規則〉，default-allow-internal 與 default-allow-icmp 的收斂在〈收斂 default-allow-internal 與 default-allow-icmp〉。

IAP 通道連不上時的依層判讀

--tunnel-through-iap 的連線失敗時，錯誤訊息與它停在哪一層對得起來：

• 錯誤訊息說 API 未啟用：連線停在 IAP 端點之前，專案上還沒有啟用 iap.googleapis.com。
• 4033（not authorized）：停在通道授權。成因是這個帳號沒有 roles/iap.tunnelResourceAccessor、IAM Conditions 不允許這個 port 或 VM、條件的期限已過，或 VM 不存在、沒有在執行；帳號實際拿不拿得到權限，以 Policy Troubleshooter 的結果為準（見〈IAP 的 IAM 授權範圍：誰拿得到通道〉）。IAM 綁定送出之後約 60 到 120 秒才生效，這段時間內的 4033 不代表條件寫錯。
• 4003（failed to connect to backend）：IAP 已經放行，連不到 VM 的那個 port。成因在網路可達性那一層：VM 沒帶 tag、新規則的網路或 port 寫錯、組織的階層式防火牆或 network firewall policy 先擋下（這類政策優先於專案規則，專案規則寫對了也連不上），或 VM 上的作業系統防火牆（ufw、firewalld、Windows 防火牆）與 sshd 沒有在監聽。防火牆這一段由 Connectivity Tests（gcloud network-management connectivity-tests create，來源給 IAP 位址段裡的一個 IP、目的地給這台 VM 與 port）模擬一次 IAP 到 VM 的連線，結果指出是哪一條規則或政策擋下；完整的指令在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈停用舊規則，用 IAP 驗證新規則〉。VM 內部的成因要從 Serial Console 進去看。
• 通道開了、登入時 Permission denied (publickey)：停在主機登入驗證。啟用了 OS Login 時，成因是 OS Login 的登入角色或 roles/iam.serviceAccountUser 缺了；沒啟用時，成因是 metadata 裡沒有這把公鑰或缺修改 metadata 的權限（見〈SSH 金鑰在 GCP 上的管理位置：metadata 金鑰與 OS Login 的啟用條件〉）。

IAP 的 IAM 授權範圍：誰拿得到通道

改走 IAP 之後，VM 的連線權限改由 IAM 決定，所以 IAM policy 的寬度就是 SSH 與 RDP 的暴露面。開通道的角色 roles/iap.tunnelResourceAccessor 可以用 IAM Conditions 限定 port（destination.port == 22）、單台 VM（destination.ip == "<vm-internal-ip>"）或期限（request.time < timestamp("<expiry-time>")），各種條件的完整指令在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈授予開通道的 IAM 權限〉。幾個地方會讓這個範圍在不知不覺中變大或對不到人：

• 專案層級的基本角色：Owner 這一類基本角色涵蓋開通道的權限，而且不受 IAM Conditions 限制。日常登入用的帳號拿掉基本角色、改授本篇列出的具體角色，Owner 只留給緊急時才用的帳號；團隊全員都是 Owner 時，IAM Conditions 對任何人都不生效，OS Login 的單台先行驗證也找不到非 Owner 的人來做。綁定之前先用 gcloud projects get-iam-policy <project-id> 列出目前持有基本角色的成員，再用 IAM 的 Policy Troubleshooter 確認某個帳號實際拿不拿得到 iap.tunnelInstances.accessViaIAP；get-iam-policy 只列出直接綁定，群組與繼承來的權限以 Policy Troubleshooter 的結果為準。稽核要一份「所有拿得到通道的人」的清單時，用 Policy Analyzer（gcloud asset analyze-iam-policy --organization=<org-id> --permissions=iap.tunnelInstances.accessViaIAP --expand-groups），--expand-groups 讓結果把 Google Group 展開成成員（預設不展開，只列到群組），要逐台列出 VM 時另加 --expand-resources；Policy Troubleshooter 一次只回答一個帳號。
• 整批授權：把 roles/iap.tunnelResourceAccessor 綁給 domain: 或大型群組，等於讓整個組織的帳號都能開通道。綁給負責維運的群組，並用 IAM Conditions 限定 port 與 VM。
• 服務帳號：CI 或自動化工具用的服務帳號若持有通道權限，它的金鑰外洩就等同一把能連進所有 VM 的鑰匙。GCP 上這類帳號用 Workload Identity Federation（Workload Identity）取得短期存取憑證，不發長期金鑰：CI 平台簽發的 OIDC token 換成服務帳號的身分，設定方式以 GCP 的 Workload Identity Federation 文件為準，與 AWS 上用 OIDC 換取 IAM role 的對照見身分與存取憑證地基 — IAM 模型、OIDC 短期憑證與權限邊界設計的〈OIDC：給 CI/CD 的短期憑證〉。服務帳號要的角色與人相同：開通道的 roles/iap.tunnelResourceAccessor，啟用 OS Login 之後另加 OS Login 的登入角色，VM 掛著服務帳號時再加那個服務帳號的 roles/iam.serviceAccountUser。
• 組織外的帳號：外包人員用他自己公司或個人的 Google 帳號時，OS Login 預設不讓組織外的帳號登入，要在組織層級另外授予 roles/compute.osLoginExternalUser（未實跑：測試帳號底下沒有 Organization）；組織若強制了 Organization Policy 的 iam.allowedPolicyMemberDomains（只允許組織網域的成員出現在 IAM 綁定裡），連綁定本身都會被拒絕；2024 年 5 月 3 日之後建立的 Organization 預設就強制這一條，用〈組織層級的護欄：Organization Policy 與階層式防火牆〉的 org-policies list 確認。這類帳號也不受組織的兩步驟驗證強制管轄，所以替外包人員在組織的 Cloud Identity 建帳號，比授權給外部帳號更容易控制，合約到期時停用帳號、或用帶 request.time 的條件讓綁定自動失效。

通道授權改用 Google 帳號之後，帳號被釣魚，攻擊者就能從 IAP 開通道。GCP 上的對應設定是在 Google Workspace 或 Cloud Identity 對能開通道的帳號強制兩步驟驗證，管理員帳號用硬體安全金鑰或 passkey 這類防釣魚的方式——一次性驗證碼會在釣魚頁面上被一起騙走。gcloud 登入之後會在本機保存 refresh token，管理員帳號停用前這份 token 一直可用，而 token 檔可以被複製；Workspace 與 Cloud Identity 的管理控制台有 Google Cloud 工作階段控制，設定多久要重新驗證一次（1 到 24 小時）；這項設定預設關閉，啟用之後這個間隔才是本機 token 被複製之後能用多久的上限，被設成受信任而豁免的應用程式不受它限制。需要再收緊時，Context-Aware Access 可以在 IAM 綁定上加 access level 條件（Access Context Manager 定義的一組連線條件，例如只允許公司管理的裝置或特定網段）。

人員異動時，移出群組或移除 IAM 綁定只擋下下一次開通道；已經開著的工作階段要另外在 VM 上結束，做法見〈SSH 金鑰在 GCP 上的管理位置：metadata 金鑰與 OS Login 的啟用條件〉最後結束工作階段的那兩段。

SSH 金鑰在 GCP 上的管理位置：metadata 金鑰與 OS Login 的啟用條件

GCP 上把 SSH 公鑰交給 Linux VM 有兩種方式，分別對應伺服器管理通道的設計〈主機登入驗證的做法：SSH 金鑰怎麼發、怎麼收回〉裡的靜態公鑰與由中央服務決定的公鑰：metadata 金鑰寫在專案或 VM 的 metadata（設在專案或 VM 上的鍵值設定）裡，由 VM 上的 guest agent（GCP 映像檔內建、把 metadata 同步進 VM 的常駐程式）寫進 authorized_keys；OS Login 依 Google 帳號與 IAM role 決定誰能登入、能不能用 sudo。寫在專案 metadata 的公鑰對專案內每一台沒有啟用 OS Login 的 VM 都生效，成員離職時漏刪一把，那把金鑰就持續能登入整個專案，而沒啟用 OS Login 時 gcloud compute ssh 預設就是把公鑰寫進專案 metadata。兩者的機制與差別見 OS Login 卡。Oracle Cloud 與 AWS 上不放金鑰時由哪些服務登入、各自包辦管理通道的哪幾層，見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉。

啟用 OS Login（metadata 的 enable-oslogin=TRUE）之後，VM 不再接受 metadata 裡的金鑰，原本靠 metadata 金鑰登入的管理員與自動化工具會立刻連不進去。啟用的順序因此由三個條件決定：

• 角色先授：每一位管理員與每一個要登入 VM 的服務帳號先拿到登入角色（roles/compute.osLogin 一般登入，roles/compute.osAdminLogin 含 sudo）；VM 掛著服務帳號時（gcloud compute instances describe 輸出的 serviceAccounts 欄不是空的，用 Google Cloud 控制台以預設值建立的 VM 會掛上 Compute Engine 預設服務帳號），每一個登入者另外需要那個服務帳號的 roles/iam.serviceAccountUser。
• 單台先行：先在單一 VM 上啟用，讓角色漏授這類錯誤只鎖住那一台；驗證要由非 Owner 的管理員做，Owner 本身持有全部權限，只由 Owner 驗證會看不出漏授。
• VM 層級蓋過專案層級：專案層級啟用之後，VM 層級設了 enable-oslogin=FALSE 的 VM 仍然讀 metadata 金鑰；專案 metadata 的 ssh-keys 留著前任與現任成員的公鑰，OS Login 一旦還原成 FALSE 它們就又能用，所以全部 VM 都啟用之後要清掉。

啟用、還原、列出 FALSE 的 VM 與清除 ssh-keys 的指令，在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈啟用 OS Login：先授角色、單台先行、再做專案層級〉。OS Login 只作用在 Linux VM，Windows VM 的登入仍由 Windows 帳號決定。OS Login 也可以要求登入時的兩步驟驗證（metadata 設 enable-oslogin-2fa=TRUE），讓每一次 SSH 登入都多一次 Google 帳號的第二因素；沒有啟用兩步驟驗證的帳號會登不進去，所以同樣先對單一 VM 設定驗證。OS Login 文件寫明這項要求不套用在服務帳號上，CI 這類登入者不受它約束。

帳號停用或角色移除之後，下一次登入就會失敗；已經建立的工作階段不受影響，所以處理離職或帳號外洩時，管理員要另外登入 VM 結束那個使用者的工作階段。在 systemd 的發行版上：

1# 結束 systemd-logind 登記過的工作階段
2sudo loginctl terminate-user <username>
3
4# 確認那個使用者的行程已經全部結束；有輸出就代表還有行程在跑
5pgrep -u <username> -a
6
7# 還有剩下的行程時，直接結束
8sudo pkill -KILL -u <username>

<username> 是 OS Login 由 Google 帳號轉成的使用者名稱，例如 alice_example_com。確認的依據是 pgrep 的輸出，而不是 terminate-user 的回傳值：loginctl 只結束 systemd-logind 登記過的工作階段，登入時 pam_systemd 登記失敗的工作階段（VM 的日誌裡有 pam_systemd(sshd:session): Failed to create session）不在它的清單裡，這時 loginctl terminate-user 會回報使用者沒有登入，而行程仍在執行。Windows VM 上用 query session 找出那個使用者的 RDP 工作階段，再用 logoff <session-id> 結束。

拿掉外部 IP 之後的出站路徑：Cloud NAT 與 Private Google Access

Cloud NAT 承接沒有外部 IP 的 VM 往外的連線，apt update、docker pull、呼叫第三方 API 都靠它；它和 AWS 的 NAT Gateway 承擔同一件事，機制見 NAT。Cloud NAT 建在 Cloud Router（GCP 管理 VPC 路由的元件）上，以 region 為單位生效，VM 分布在幾個 region 就要各建一組；出站 IP 可以讓 GCP 自動配發（可能變動），或改用預留的靜態 IP（外部服務要求來源 IP 白名單時）。VM 要存取 Cloud Storage、Artifact Registry 這類 Google API 時，subnet 開啟 Private Google Access，就能用內部 IP 連到 Google API，不經過 Cloud NAT，也就不產生 NAT 的資料處理費。

拿掉外部 IP 的判斷有兩點：

• 哪些 VM 可以拿：對外提供服務的 VM（網站、API）移除外部 IP 之前，要先把流量入口換到負載平衡器，否則移除的當下服務就中斷，入口層的設計見流量入口層 — 請求怎麼從使用者到達應用。只做管理用途的 VM 可以直接移除。
• 驗證要在移除之後做：網卡還帶著外部 IP 時，Cloud NAT 不處理這張網卡的出站流量，流量走的是 VM 自己的外部 IP，所以移除之前測出站一定是通的，證明不了 Cloud NAT 有效。移除之後在 VM 上看出站的來源 IP，判斷依據是那個 IP 在不在 Cloud NAT 的 IP 清單（gcloud compute routers get-nat-ip-info）裡，而不是移除前後的 IP 有沒有變：自動配發的 Cloud NAT 可能正好配到這台 VM 剛釋放的那個外部 IP。

建 Cloud NAT、開 Private Google Access、查 access config 名稱與移除外部 IP、驗證出站的指令與實跑結果，在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈建 Cloud NAT 並移除外部 IP〉。移除之後，這台 VM 只剩 IAP 一條管理路徑，連線一律加 --tunnel-through-iap。

組織層級的護欄：Organization Policy 與階層式防火牆

default 網路與 default-allow-ssh、default-allow-rdp 這些預設規則，每個新建的專案都會重新長出來，所以單一專案的收斂只保護那一個專案。要讓組織裡的新專案不再帶著這些規則，在 Organization Policy 設定下面幾個 constraint。這一節的指令需要專案屬於一個 Organization 資源，執行者要有組織層級的權限（roles/orgpolicy.policyAdmin 與 roles/compute.orgFirewallPolicyAdmin）；這一節的指令沒有實跑（測試帳號底下沒有 Organization）。2024 年 5 月 3 日之後建立的 Organization 會預設強制一組 constraint，先用 gcloud resource-manager org-policies list --organization=<org-id> 看哪些已經生效。

• compute.skipDefaultNetworkCreation：新專案不再自動建立 default 網路。
• compute.vmExternalIpAccess：只允許列在清單上的 VM 持有外部 IP，其餘 VM 建立時帶外部 IP 會被拒絕。
• compute.requireOsLogin：新建的專案與 VM 啟用 OS Login，任何層級都無法用 metadata 把它關掉；既有 VM 是否已啟用要另外盤點，而既有的管理員要先拿到 OS Login 的登入角色。
• compute.disableSerialPortAccess：關閉 Serial Console 的存取，讓救援入口平時保持關閉；救援時由持有組織政策權限的人對那個專案解除，救援結束後恢復。

 1# 在組織層級強制布林型的 constraint（skipDefaultNetworkCreation、requireOsLogin、disableSerialPortAccess 同一種寫法）
 2gcloud resource-manager org-policies enable-enforce compute.skipDefaultNetworkCreation \
 3  --organization=<org-id>
 4
 5# 救援時，對單一專案解除 Serial Console 的限制
 6gcloud resource-manager org-policies disable-enforce compute.disableSerialPortAccess \
 7  --project=<project-id>
 8
 9# 救援結束後，刪掉專案層級的例外，讓專案重新繼承組織層級的強制
10gcloud resource-manager org-policies delete compute.disableSerialPortAccess \
11  --project=<project-id>

<org-id> 用 gcloud organizations list 查。compute.vmExternalIpAccess 是清單型的 constraint，要用政策檔列出允許的 VM，寫法以 Organization Policy 文件為準。

階層式防火牆政策（hierarchical firewall policy）套用在組織或資料夾上，優先於專案的 VPC 防火牆規則評估。政策裡的規則依 priority 數字由小到大評估，命中 allow 或 deny 就停止，專案的規則不會再被看到；命中 goto_next 則把這條連線交給下一層（最終是專案的 VPC 規則）判斷。所以規則的相對 priority 決定結果：

• 交給專案判斷的 IAP 規則（來源 35.235.240.0/20，有 IPv6 VM 時加上 2600:2d00:1:7::/64；tcp:22 與 tcp:3389；動作 goto_next）priority 要比拒絕規則小，否則 IAP 的流量先被拒絕規則擋下。它用 goto_next 而不用 allow：allow 會讓 IAP 的位址段直接通到組織內每一台 VM，繞過專案用 target tag 做的收斂。
• VM 之間或從 VPN 進來的 SSH 需要保留時，它們的來源（內部網段、VPN 的位址段）同樣要有一條 priority 比拒絕規則小的 goto_next 規則，因為拒絕規則的 0.0.0.0/0 也涵蓋內部位址。
• 拒絕 0.0.0.0/0 連到 tcp:22 與 tcp:3389 的規則只涵蓋 IPv4，IPv6 要另寫一條拒絕 ::/0 的規則，這兩條拒絕規則之間沒有先後依賴。

 1# 建立組織層級的防火牆政策，加入規則，再關聯到一個資料夾（之後再關聯到組織）
 2gcloud compute firewall-policies create --short-name=<policy-name> --organization=<org-id>
 3
 4gcloud compute firewall-policies rules create 100 --firewall-policy=<policy-name> \
 5  --organization=<org-id> --direction=INGRESS --action=goto_next \
 6  --src-ip-ranges=35.235.240.0/20 --layer4-configs=tcp:22,tcp:3389
 7
 8gcloud compute firewall-policies rules create 1000 --firewall-policy=<policy-name> \
 9  --organization=<org-id> --direction=INGRESS --action=deny \
10  --src-ip-ranges=0.0.0.0/0 --layer4-configs=tcp:22,tcp:3389
11
12gcloud compute firewall-policies associations create --firewall-policy=<policy-name> \
13  --organization=<org-id> --folder=<folder-id>

100、1000 是規則的 priority，只要 goto_next 那幾條比拒絕規則小就行，中間留空號給之後要插入的規則。<policy-name> 是自己取的政策名稱。--folder=<folder-id> 把政策關聯到一個資料夾；組織與資料夾層級的政策影響其下每一個專案，先關聯到一個測試用的資料夾，確認既有服務沒有依賴被擋掉的路徑，再關聯到組織（拿掉 --folder）。

稽核與偵測：firewall log、Cloud Audit Logs 與 Security Command Center

伺服器管理通道的設計〈組織層級的護欄與稽核紀錄〉列出事後要查的三項事件，在 GCP 上分別從這幾個來源查：

• 誰在什麼時候經由哪條通道登入了哪台 VM：開通道的帳號與目標 VM 記在 Cloud Audit Logs 裡 IAP 的 Data Access 紀錄，要為 Cloud Identity-Aware Proxy 開啟「管理員讀取」（ADMIN_READ）類型才有：開通道時 IAP 檢查的權限 iap.tunnelInstances.accessViaIAP 歸在這個類型，只開「資料讀取」（DATA_READ）時，實測連了十次左右，開通道的紀錄一筆都沒有。開啟之後經由 IAP 連一次、查到方法名稱為 AuthorizeUser 的紀錄才算開對，查詢指令在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈啟用 IAP API、開啟稽核紀錄並建立只放行 IAP 來源的防火牆規則〉。登入 VM 的帳號記在 VM 上的 sshd 紀錄，啟用 OS Login 時是由 Google 帳號轉成的使用者名稱。啟用 OS Login 時，每一次登入另外在 Cloud Audit Logs 留下 OS Login 檢查登入權限的 Data Access 紀錄，記著 Google 帳號與目標 VM，而且存在 VM 之外，取得 VM root 的人清不掉：

  1# 列出最近七天每一次 OS Login 的時間、Google 帳號與目標 VM；--freshness 依調查範圍調整
  2gcloud logging read 'protoPayload.serviceName="oslogin.googleapis.com" AND protoPayload.methodName:"CheckPolicy"' \
  3  --freshness=7d --format="value(timestamp,protoPayload.authenticationInfo.principalEmail,protoPayload.resourceName)"

  實測的專案沒有為 Cloud OS Login API 另外開啟 Data Access 紀錄，CheckPolicy 的紀錄仍然寫進了 data_access 這個紀錄檔；查不到時，到「IAM 與管理 > 稽核記錄」確認 Cloud OS Login API 的 Data Access 設定，並用 gcloud projects get-iam-policy <project-id> --format="json(auditConfigs)" 看專案層有沒有排除它。firewall rules logging 記錄每一次放行的來源 IP、目的 VM、port 與命中的規則名稱，經由 IAP 的連線來源都是 IAP 的位址段，從這份紀錄看不出是哪個人。

• 誰在什麼時候開了救援入口：開啟 Serial Console 的 metadata 修改與組織政策的解除屬於 Admin Activity 紀錄，預設就有。

• 環境裡是否出現新的對外開放管理 port：Security Command Center 的 Security Health Analytics 持續掃描組織內的防火牆規則，OPEN_SSH_PORT 與 OPEN_RDP_PORT 這兩類 finding 對應的就是對外開放 22 與 3389 的規則。處理方式是照〈切換到 IAP 的順序〉把規則換掉（逐步指令在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄），直接刪除會中斷管理員自己的連線；規則刪除或縮小來源之後，下一次掃描會把對應的 finding 標為已解決。

事件發生時才發現 IAP 的 Data Access 紀錄沒開，開啟之前的通道紀錄查不回來，剩下的來源是 Admin Activity 紀錄裡 metadata 與 IAM 的變更，以及 VM 上的 sshd 紀錄；sshd 紀錄只存在 VM 本機，取得 root 的攻擊者可以清掉，所以要保全時先把 VM 的磁碟做快照，證據的保全與分流見 8.18 Incident Intake & Evidence Triage。

AWS 上同類的盤點流程見 Security Group 稽核與清理：兩邊都是先列出來源是 0.0.0.0/0 的規則，逐條確認有沒有服務依賴，再刪除或縮小來源。

延伸閱讀：逐步的實作、與廠商無關的設計模型與 VPC 的分層規則

• → GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄：盤點、救援入口、IAP 規則與 IAM、停用舊規則驗證、OS Login 啟用與移除外部 IP 的逐步指令、實跑看到的輸出，以及每一步沒做或換一種做法時的結果
• → 伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的做法與選擇，以及救援入口：跳板機、VPN、代理程式反向連線、SSH 憑證這些 GCP 以外的做法，以及依存取者身分、代理把連線送進主機的方式、金鑰收回方式選擇組合的依據
• → OpenSSH 內建 CA 的 SSH 憑證導入：主機不全在 GCP、OS Login 用不上時，改用 SSH 憑證讓登入權限自動到期
• → GCP 上由 MIG 與 GKE 管理的 VM 的管理存取：本篇的 tag、OS Login 與移除外部 IP 在 instance template 與 node pool 上的寫法，以及 GKE 控制平面的存取
• → 網路地基 — VPC、subnet 分層與 security group 設計：VPC 與 subnet 的分層與最小開放原則，本篇的防火牆規則是同一套原則在 GCP 上的寫法

autohealing、滾動更新與擴增後消失的逐台設定：network tag、OS Login metadata 與外部 IP

MIG 裡的每一台 VM 都由 instance template 建出來。有幾種時機 MIG 會依 template 重建或替換一台 VM，原本開機磁碟上的修改都不會留下：自動修復（autohealing，健康檢查失敗時重建）、滾動更新（rolling update，換成新版 template），以及 GKE 的節點升級與節點自動修復；autoscaler 擴增台數時則直接依 template 新建。新建的 VM 只帶著 template 裡的設定，所以單台 VM 上做的修改——gcloud compute instances add-tags 加的 network tag（貼在 VM 上的標籤，防火牆規則用它選出要套用的 VM）、add-metadata 設的 enable-oslogin、登入之後 useradd 建的救援帳號、delete-access-config 移除的外部 IP——都只活到那台 VM 被重建為止，新加進來的 VM 則從一開始就沒有。

這種消失沒有任何通知。重建通常發生在半夜的自動修復或下一次擴增，而只放行 IAP 來源的防火牆規則靠 network tag 選 VM：新建的 VM 沒有那個 tag，這條規則就套不到它。收斂管理通道時通常也已經刪掉 default-allow-ssh（GCP 預設網路裡放行任何來源連 22 port 的規則），兩者加在一起，新 VM 上沒有任何一條規則放行 SSH，它就從管理通道上消失了。所以這兩種環境的做法是：管理通道的設定寫在建立 VM 的那一份設定裡（MIG 的 instance template、GKE 的 node pool 設定、或映像檔），逐台的 gcloud compute instances 指令只用在臨時查看。

instance template 建立之後不能修改，改設定的方式是建一份新的 template，再讓 MIG 滾動更新到新版；instance-templates create 從預設值開始建、不沿用舊 template 的任何設定，所以新 template 要把現行設定逐項帶上，漏掉的欄位會回到預設值。新版先讓一台 VM 換上（canary），驗證通過再讓整組更新，template 寫錯時才只壞一台；建新 template 與 canary 的指令在 GCP 上 MIG 與 GKE 管理存取的實測紀錄 的〈建新的 instance template：現行設定照抄，再加 tag、OS Login 與不配外部 IP〉與〈先讓一台 VM 換成新 template（canary），再讓整組更新〉。MIG 與 GKE 多半由 Terraform 這類 IaC 工具管理，這時 template 與 node pool 的修改都改在程式碼裡：在 CLI 上建的 template、改的 node pool 設定，下一次 apply 會依程式碼改回去，這種程式碼與實際狀態的落差叫 drift，過渡期的做法見兩套真相並存的過渡期操作。

要判斷一台 VM 屬不屬於 MIG，看它的 metadata（掛在 VM 上的鍵值設定，VM 內的程式與有讀取權限的帳號都讀得到）有沒有 created-by 這個鍵（值是那個 MIG 的資源路徑）。這個鍵由 MIG 在建立 VM 時寫入，VM 被移出 MIG（abandon）之後仍然留著，所以它標出的是建立這台 VM 的 MIG；要確認 VM 現在是否仍是那個 MIG 的成員，用 gcloud compute instance-groups managed list-instances <mig-name> --zone=<zone> 列出 MIG 目前的 VM 來對照。GKE 節點帶著 goog-gke-node 標籤。下面的指令用 jq（命令列的 JSON 處理工具）從 gcloud 的 JSON 輸出取出這個鍵，要先在本機裝好；gcloud 讀的是目前設定的專案，要查別的專案時加 --project=<project-id>：

1# 列出 VM 與它所屬的 MIG（第二欄是 - 的就是單獨建立的 VM）
2gcloud compute instances list --format=json \
3  | jq -r '.[] | [.name, (first((.metadata.items // [])[] | select(.key=="created-by") | .value) // "-")] | @tsv'

GKE 的節點同樣是 MIG 的成員，這條指令會把它們列成屬於某個名稱是 gke-...-grp 的 MIG。這類 MIG 由 GKE 管理：對它們建 template、滾動更新或 recreate-instances，改動會被 GKE 覆蓋或讓叢集狀態不一致，recreate-instances 也不會先把節點上的 Pod 移走。帶著 goog-gke-node 標籤的 VM 改走本篇 GKE 的幾節：設定改在 node pool，單一節點壞掉時用 kubectl drain 移走 Pod，再交給 GKE 的節點自動修復。

MIG 的救援：重建、退回舊版 template 與 Serial Console 各自適用的情形

單台 VM 的救援入口是 Serial Console 加一個事先建好的本機救援帳號（Serial Console（序列主控台））。MIG 裡的 VM 多了兩條路，各自適用的情形不同：

• 依 template 重建那一台（recreate-instances）：一台 VM 連不上、而原因是那台 VM 自己壞了（sshd 設定改壞、磁碟滿）時，讓 MIG 依 template 重建它，比從 Serial Console 進去修快，也不必替每台 VM 維護救援密碼。重建的前提是 VM 上沒有只存在那一台的狀態：資料寫在外接的資料庫、物件儲存或另外掛載的磁碟上，VM 本身隨時可以丟。VM 上有不能丟的狀態時，MIG 的 stateful 設定把指定的磁碟、IP 與 metadata 標為要保留；狀態多到每台都不一樣時，它更適合當單獨的 VM 管理。
• 退回上一版 template：重建修不好的是 template 本身的錯（tag 寫錯、啟動腳本有錯），重建出來的每一台都一樣壞，這種錯要整組退回上一版，所以舊版 template 留到新版驗證完之後再刪。
• Serial Console：需要登入一台壞掉的 VM 查原因、保留現場做事後分析時仍然可用。救援帳號的帳號與密碼雜湊要在建立映像檔時寫進去（用 Packer 這類建映像檔的工具，或在一台 VM 上建好帳號再把磁碟做成自訂映像檔），而不是寫進 template 的 startup-script，因為 startup-script 存在 metadata 裡，任何有讀取 metadata 權限的人都看得到，把密碼寫在那裡等於公開。寫進映像檔的代價是整組 VM 共用同一組密碼雜湊，要輪替就要重做映像檔、再滾動更新一次。

重建之後要知道的一件事是主機金鑰換了：重建在原地換掉開機磁碟，VM 沿用原本的名稱與執行個體 ID，而 gcloud compute ssh 在本機用 compute.<instance-id> 記錄主機金鑰，所以第一次連線會出現 WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 並拒絕連線。這個警告也是中間人攻擊時會看到的訊息，處理方式是先用不經過這條 SSH 連線的來源（guest attributes 回報的主機金鑰；guest attributes 是 VM 寫回 metadata server、可以經由 GCP API 讀取的鍵值，要事先設 enable-guest-attributes=TRUE）確認新的金鑰確實來自這台 VM，再移除舊紀錄，不關掉主機金鑰檢查。重建與退回的指令、重建做完的確認方式與主機金鑰的比對，在 GCP 上 MIG 與 GKE 管理存取的實測紀錄 的〈重建一台壞掉的 VM：recreate-instances 與重建之後的主機金鑰〉與〈template 本身寫錯時退回上一版〉；Serial Console 的開啟與救援帳號的登入，在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈準備救援入口：Serial Console 與本機救援帳號〉。

GKE 的存取面：控制平面與節點

GKE 叢集有兩個不同的存取面，設計時要分開處理：

• 控制平面：Kubernetes 的 API server，kubectl 連的就是它。日常的部署、查 log、進 Pod 執行指令都經過它，這是 GKE 上的主要管理通道。
• 節點（node）：跑工作負載的 VM。節點的作業系統要登入的情形很少：GKE 管理節點的映像檔、升級與修復，節點本身也是隨時可以丟的。

多數團隊在 GKE 上不需要節點的 SSH：查 Pod 的狀況用 kubectl logs、kubectl exec，查節點的狀況先看 Cloud Logging 裡的節點紀錄，需要看到節點作業系統時用 kubectl debug node。所以在 GKE 上收斂管理通道時，工作集中在控制平面的存取，節點的 SSH 盡量關掉。

GKE 有兩種叢集模式：Standard 由使用者管理 node pool 與節點設定；Autopilot 由 GKE 管理節點，使用者只管工作負載。〈kubectl debug node 的權限邊界：RBAC 與 Pod Security Admission〉裡建專用 namespace 與節點 SSH 的做法只適用於 Standard。

kubectl debug node 的權限邊界：RBAC 與 Pod Security Admission

kubectl debug node/<node-name> 在指定的節點上建一個 Pod，把節點的根目錄掛在 Pod 的 /host，讓管理員經由 Kubernetes API 看到節點的作業系統，不需要節點開 SSH；進到 Pod 之後 chroot /host（把行程的根目錄換成 /host），之後執行的指令看到的是節點的檔案系統。不加 --profile 時，較新的 kubectl 用預設的 general profile（舊版的預設是 legacy），除錯 Pod 已經以 root 執行、共用節點的行程、網路與 IPC 的 Linux namespace，讀寫節點的檔案、用 crictl 列出節點上的容器都做得到；--profile=sysadmin 以特權容器（privileged container）執行，多給的是需要額外 Linux capability（核心把 root 權限拆成的個別權限項）的操作。

這個做法的權限邊界有兩道。Kubernetes RBAC 決定誰能用它：在除錯 Pod 所在的 namespace 要有 pods 的 create（建 Pod）、list 與 watch（kubectl 用 watch 等 Pod 進入執行狀態）、delete（用完刪掉），以及 pods/attach 的 create（-it 在 Pod 建好之後附加到它的終端機），這幾項綁在那個 namespace 的 RoleBinding；另外要有 nodes 的 get，節點不屬於任何 namespace，這一項要用 ClusterRoleBinding 授予。少了 list 或 watch 時 Pod 已經建好，kubectl 卻停在等待；少了 pods/attach 時 Pod 建得出來卻進不去；兩種情形都會留下一個在跑的除錯 Pod。

能在節點上建除錯 Pod 的帳號，用預設的 general profile 就能以 root 讀寫節點的檔案，所以這組權限只給負責維運的群組。Pod Security Admission 決定那個 namespace 是否接受這類 Pod：kubectl debug node 用 general 或 sysadmin profile 建的 Pod 帶著主機的網路、行程與 IPC 的 Linux namespace（hostNetwork、hostPID、hostIPC）與主機目錄掛載（hostPath），namespace 設了 pod-security.kubernetes.io/enforce=baseline 或 restricted 時，這幾項都會讓除錯 Pod 被拒絕；用 --profile=baseline 或 restricted 建的除錯 Pod 不帶這些設定，建得進這類 namespace，但看不到節點的檔案。反過來，沒有設這個 label 的 namespace（包括 default）在 GKE Standard 上預設接受特權 Pod，所以任何能在 default 建 Pod 的帳號，現在就能用這個方法以 root 操作節點。做法是把一般工作負載的 namespace 都設成 baseline 以上，節點除錯集中到一個刻意保留為 privileged 等級、而且只有維運群組能建 Pod 的 namespace，由叢集管理員事先建好；建法與使用的指令在 GCP 上 MIG 與 GKE 管理存取的實測紀錄 的〈GKE 節點除錯：建專用的 namespace，用 kubectl debug node 查看節點〉。GKE Autopilot 預設拒絕特權 Pod（只有列入允許清單的合作夥伴工作負載例外），也不提供節點 SSH，查節點層的狀況靠 Cloud Logging 裡的節點紀錄與 GKE 主控台的節點狀態。

節點仍要 SSH 時（GKE Standard），單台 VM 的三項設定搬到 node pool 上：節點不配外部 IP 的 private nodes（先要有 Cloud NAT，換成內部 IP 之後節點的出站都經過它）、node pool 的 network tag（node-pools update --tags 整組取代使用者設定的 tag，GKE 自建的 tag 不受影響），以及 OS Login。Autopilot 叢集不能用 OS Login，因為節點由 GKE 管理。專案層級的 enable-oslogin=TRUE 是否套用到 GKE Standard 的節點，GKE 自己的兩份文件寫法相反：OS Login 的設定頁說專案層的設定套用到專案裡所有既有與新建的 VM，node pool 的管理頁則寫 OS Login 在 GKE 節點上被明確停用，所以啟用之後經由 IAP 實際登入一個節點，以登入後的帳號判斷。三項設定的指令在 GCP 上 MIG 與 GKE 管理存取的實測紀錄 的〈node pool：private nodes、network tag 與 OS Login〉。

GKE 控制平面的存取：authorized networks、DNS-based endpoint 與 private endpoint

控制平面的 API server 預設有一個公開的 IP 端點，任何地方都連得到，靠 Kubernetes 的認證（通道授權）與 Kubernetes RBAC（主機登入驗證那一層的對應）擋下沒有權限的請求——在管理通道的模型裡，這等於網路可達性全開，與 0.0.0.0/0 開 22 port 是同一種狀態。收窄網路可達性的做法有三種：

• authorized networks：只允許列出的來源 IP 範圍連到 API server 的 IP 端點，相當於來源 IP 白名單，代價與白名單相同（遠端工作、IP 會變動時要一直改，而且分辨不出個人）。清單每次都整組取代，執行指令的人與 CI 的出口 IP 漏列時 kubectl 當場連不上，而 gcloud 不經過這個端點，連不上時仍可以改回。設了 authorized networks 之後，GCP 上其他客戶的 VM 的外部 IP 是否放行，由叢集的 Google Cloud 外部 IP 存取設定決定（gcpPublicCidrsAccessEnabled，要明確設定過一次才會出現在 describe 的輸出裡）。
• DNS-based endpoint：叢集多一個專屬的網域名稱端點，請求先經過 Google Cloud、以 IAM 判斷這個帳號能不能連到這個叢集（container.clusters.connect 權限，roles/container.developer 這類角色裡有），通過之後才轉到 API server。它相當於控制平面前面的身分感知代理：網路可達性與通道授權改由 IAM 承擔，不必維護 IP 清單，GitHub Actions 這類外部 CI 也能用 workload identity federation 換到的身分連進來，不必另架跳板機。啟用之後 IP 端點仍然開著，每個人與每條 CI 都改連網域名稱端點之後才關掉 IP 端點；兩步分開是因為關掉 IP 端點的那一刻，還在用它的人與 CI 當場連不上。
• private endpoint：控制平面只留內部 IP 端點（--enable-private-endpoint），只有 VPC 內與經 VPN 或 Interconnect 接進 VPC 的來源連得到，可以再加 --enable-authorized-networks-on-private-endpoint 收窄到 VPC 內的特定範圍。既有的 private cluster 多半是這種設定，從 VPC 外管理時要經過 VPN 或跳板機；改用 DNS-based endpoint 之後這一層可以拿掉。

三種做法的指令、兩步切換的確認方式與實跑結果，在 GCP 上 MIG 與 GKE 管理存取的實測紀錄 的〈控制平面：authorized networks，或改連 DNS-based endpoint 再關掉 IP 端點〉。

一個 kubectl 請求要通過兩次檢查。連進叢集的檢查是 IAM 的 container.clusters.connect：經 DNS-based endpoint 連線時缺了它，請求在進到 API server 之前就被 Google 的前端以 403 Forbidden 擋下。請求進到 API server 之後，API server 再判斷這個帳號是否有權限執行這個請求（例如列出節點），這項授權檢查在 GKE 上由 IAM 與 Kubernetes RBAC 共同決定，兩者任一個允許就放行：IAM 的 Kubernetes 物件權限（例如 container.nodes.list，roles/container.developer 這類角色裡有）或 RBAC 的 Role 與 RoleBinding。只拿到 container.clusters.connect（例如 roles/container.clusterViewer）的帳號連得進叢集，列出節點時會收到 nodes is forbidden: User "<email>" cannot list resource "nodes"，訊息後面寫著它要的 IAM 權限名稱。IAM 與 RBAC 的授權要一起設計，原則與 GCP VM 的 SSH 與 RDP 管理通道〈IAP 的 IAM 授權範圍：誰拿得到通道〉相同：綁給負責維運的群組，不綁給整個網域。

延伸閱讀：逐步的實作、單台 VM 的做法、管理通道模型與 IaC 的落差

• → GCP 上 MIG 與 GKE 管理存取的實測紀錄：新 template 與 canary、重建與主機金鑰、退回 template、除錯 namespace、node pool 設定與控制平面端點切換的逐步指令、實跑結果，以及每一步換一種做法時的結果
• → GCP VM 的 SSH 與 RDP 管理通道：本篇沿用的 IAP 規則、IAM 權限、OS Login 與 Cloud NAT 在單台 VM 上的機制與切換順序
• → 伺服器管理通道的設計：網路可達性、通道授權、主機登入驗證三層的模型，以及不可變基礎設施下平時關閉通道的做法
• → 兩套真相並存的過渡期操作：MIG 與 GKE 多半由 IaC 管理，在 CLI 上建的 template 與改的 node pool 設定要寫回程式碼

文中的觀察來自 2026 年 10 月在一個 GCP 測試專案上的實跑；標「未實跑」的做法沒有在實跑中執行；引用 Cloud Billing 文件或 gcloud 說明的行為，出處寫在句子裡。主控台的選項與服務清單會變動，以操作當下看到的為準。

費用失控的來源與反應時間

費用失控指的是費用增加的速度快過人發現它、處理它的速度。來源分成兩類，兩類的處置方式不同：

• 服務自己出錯：程式對失敗的請求無限重試、一個事件觸發的函式又產生同一種事件而形成遞迴、自動擴縮允許的最大執行個體數設得太高。費用花在自己的服務上，修好程式之後費用就停止增加。
• 資源被別人濫用：外洩的 API 金鑰（API key）被拿去呼叫付費 API、被入侵的 VM 被拿去挖礦。費用花在攻擊者的用途上，處理的人要先切斷攻擊者能用的資源，再處理入侵。

兩類的共同難處在時間：費用從發生到任何機制動作，中間隔著一段延遲。一個防護機制從費用發生到動作，要經過三段：雲端把用量算成費用、寫進帳單資料；帳單資料觸發通知；通知觸發處置（人或程式）。把用量算成費用那一段的延遲由雲端決定，GCP 的帳單主控台寫著費用資料要數小時後才會顯示、有時超過 24 小時。實測時一個專案已經跑了幾個小時的 VM 與 GKE 叢集，那段期間送到的預算通知裡 costAmount（本期累計花費）仍是 0.0；那個預算用預設的抵免設定，所以這次分不出 0.0 來自延遲還是抵免。

預算警示與由預算通知觸發的處置讀的是帳單資料，反應時間至少是這段延遲。強制執行支出上限依的是 GCP 估算的費用，Cloud Billing 文件說這份估算比帳單報表上的費用快得多，但仍不是即時，延遲期間超出上限的部分照常計費。這三個機制的費用最後停在哪裡也不同：

• 強制執行支出上限與解除帳單連結：費用停止增加，總額是觸發的金額再加上延遲期間已經發生的費用。
• 只停止花錢的資源：被停掉的資源不再計費，磁碟與儲存照常計費。
• 預算警示：不停止任何用量，費用停在哪裡取決於收到通知的人多快處理。

要在費用發生的當下限制它，得靠不經過帳單資料的限制，它們也決定了延遲期間最多能多花多少：

• 能用多少：API 的配額、速率限制（rate limit）、服務允許的最大執行個體數（例如 Cloud Run 的 --max-instances、MIG 的最大台數），以及 Compute Engine 的區域 CPU 與 GPU 配額。配額調到實際用量附近，被入侵的帳號能開的 VM 台數就有上限。
• 能建什麼：組織政策（Organization Policy，GCP 繁體中文介面寫作「機構政策」）可以限制專案能啟用的 API，搭配 Compute Engine 的自訂限制條件可以限制能用的機型，前提是專案屬於一個組織（未實跑：測試帳號底下沒有組織）。
• 金鑰能做什麼：API 金鑰的使用範圍限定可呼叫的 API 與來源；實測 gcloud services api-keys create 不給 --api-target 時被拒，新建的金鑰一定帶 API 範圍。金鑰被盜用時，先撤銷或限制那一把金鑰，影響範圍比停用整個專案的帳單小。

預算警示：門檻依據、範圍、抵免與通知對象

預算（budget）是建在帳單帳戶上的一組門檻：本期花費達到預算的某個比例時，GCP 寄通知給帳單帳戶的管理員。門檻有兩種依據，實際花費（已經寫進帳單資料的費用）與預測花費（GCP 依目前的速度推估到期末的費用）；預測花費的門檻通常比實際花費的門檻早觸發，代價是一次短暫的尖峰也可能觸發預測花費的門檻。預算只寄通知，扣款照常進行。建立指令（gcloud billing budgets create 加 --filter-projects、--threshold-rule）與它的兩道權限檢查，在 GCP 預算警示與停損開關的實測紀錄 的〈建立限定一個專案的預算〉。

決定一個預算會不會在對的時候通知對的人，有三件事：

• 範圍：預算用 --filter-projects 限定要計算的專案。gcloud 說明寫著不給這個旗標時涵蓋所有專案，通知裡的 costAmount 就是帳單帳戶下所有專案的合計：別的專案的花費也會讓它越過門檻，而這個專案自己的超支被合計稀釋。
• 抵免：gcloud 說明寫著預設把帳戶上的抵免扣掉之後才算花費。帳戶上有大額抵免（新創方案、試用額度）時，costAmount 在抵免用完之前都接近 0，門檻在抵免被燒光的整段期間都不會觸發。抵免本身也是要保護的錢時，建立預算時加 --credit-types-treatment=exclude-all-credits，花費以抵免前的金額計算，代價是免費方案的用量也會以原價算進去（推論：FREE_TIER 是預算接受的抵免類型，這次沒有量）；只想讓部分抵免照常扣掉時，改用 include-specified-credits 搭配 --filter-credit-types。試用額度用完或試用期結束之後，帳單帳戶與資源會被停用、停止還是開始計費，GCP 與 Oracle Cloud、AWS 的規則見 雲端免費額度與小型主機的收費比較 的〈試用結束後帳號與資源的處置〉。
• 通知對象：通知預設寄給帳單帳戶的管理員與帳單使用者，建立預算時先確認這兩個角色的成員信箱有人在看。值班的人通常不在這兩個角色裡，要讓他們收到，把通知另外寄到 Cloud Monitoring 的電子郵件通知管道（Cloud Billing 文件寫明預算只支援電子郵件類型的管道）；要送到簡訊、聊天工具或 webhook，改由 Pub/Sub 主題接一段轉送程式。

預算另外可以把通知送到一個 Pub/Sub 主題（topic），由預算通知觸發的處置就是從這個主題接收通知；接法在 GCP 預算警示與停損開關的實測紀錄 的〈建接收通知的主題並把預算接上〉。預算警示沒有辦法手動送出一封測試用的門檻通知，第一封真實的門檻通知寄到之前，「通知送得到收的人」這一段沒有驗證過；寄到時確認收到的是誰、多久後有人看到。

強制執行支出上限：涵蓋的服務、範圍與暫停期間

在帳單主控台的「Budgets & caps」頁面（2026 年 10 月主控台顯示的名稱）建立預算時，表單裡有一個「強制執行支出上限（適用於某些服務）」的選項：花費達到上限時，GCP 暫停表單裡選定的那個專案、那一項服務的新用量，直到這個預算期間結束（以月為期的預算是到月底，下一期自動重設）或有人手動解除為止。它是帳單功能裡不必自己寫程式就能暫停用量的機制，範圍有四個限制：

• 一個上限只涵蓋一個專案裡的一項服務：要保護多項服務，就每項各建一個。
• 只涵蓋清單上的服務：2026 年 10 月建立表單時列出的是 Cloud Run、Cloud Run functions、Gemini API 與 Vertex AI 四項，Compute Engine 與 GKE 不在清單上。表單的服務下拉選單就是涵蓋清單，建立之前打開看一次。
• 持續性資源的固定費用不暫停：Cloud Billing 文件說明，與持續性資源綁在一起的固定用量不會被暫停，執行也有延遲，超出的部分照常計費。
• 以抵免前的金額計算：Cloud Billing 文件寫明上限的花費不扣抵免與折扣，與預算的預設抵免設定相反。帳戶有抵免、而上限與預算的金額相近時，上限會先達到。

工作負載跑在清單上的服務時，這個選項不必寫程式；它暫停的是這項服務的新用量，所以對正式服務同樣是一次停機，只是範圍限於這一項服務。是否建立，依〈由預算通知觸發的處置：解除帳單連結與只停止花錢的資源〉比較的兩種損失（多付的費用，與服務停止、資料可能遺失）來判斷。一個專案同時有清單上的服務與不在清單上的服務時，兩種做法可以並用：清單上的服務各建一個支出上限，在估算費用達到上限時先暫停那一項服務；不在清單上的資源由只停止花錢的資源那一種處置接手。改用解除帳單連結的話，停掉的是整個專案，清單上的服務也一起停。

由預算通知觸發的處置：解除帳單連結與只停止花錢的資源

這一節的做法是讓預算通知觸發一段程式，由程式在花費達到預算時停止用量。停止用量有兩種做法，差別在停掉的範圍：

• 解除帳單連結：程式呼叫 Cloud Billing API 把專案從帳單帳戶解除連結。專案沒有連結帳單帳戶時，GCP 停止專案裡所有的服務（包括免費方案的服務），費用也就停止增加。這段程式在下文稱為停損開關（kill switch）。
• 只停止花錢的資源：程式改成停止專案裡執行中的 VM、把 MIG 的目標台數設成 0、把 GKE node pool 縮到 0 個節點。Cloud Billing 文件的〈Control resource usage with notifications〉就是這種做法，範例是逐台停止一個 zone 裡執行中的 VM。實測改用 instances().aggregatedList 跨全部 zone 列出 RUNNING 的 VM 再逐台 stop，服務帳號只給 roles/compute.instanceAdmin.v1：訊息發出後函式立刻送出停止，VM 約兩分鐘後變成 TERMINATED，帳單仍是啟用、開機磁碟仍在。資料留在磁碟與儲存裡、那部分照常計費，所以費用不會歸零；代價是程式只停它列得出來的資源，漏掉一種資源型別，或攻擊者另外開的新資源，那部分照常計費。

呼叫鏈上的 Eventarc 是 GCP 把事件（這裡是主題裡的訊息）轉成對函式的呼叫的服務；第二代的 Cloud Run functions 以 Eventarc 觸發器接主題。

1預算（帳單帳戶）── 通知 ──> Pub/Sub 主題 ── 推送 ──> Eventarc 觸發器 ── 呼叫 ──> Cloud Run functions 函式 ──> 解除帳單連結，或停止花錢的資源

兩種做法的預算、主題、觸發器與重試設定相同，差別在函式本體、服務帳號的角色與驗收的終點：改成只停止花錢的資源時，函式改成呼叫 Compute Engine 與 GKE 的 API，服務帳號改給能修改那些資源的角色（VM 與 MIG 例如 roles/compute.instanceAdmin.v1，GKE node pool 的縮放要 container 的權限，以 gcloud iam roles describe 確認），驗收的終點改成超出預算的訊息之後 gcloud compute instances list 的狀態變成 TERMINATED、MIG 的目標台數與 node pool 的節點數變成 0，每一個 zone 與資源型別各確認一次（MIG 與 node pool 的部分未實跑）。

建之前先決定要不要建、建哪一種，因為停損開關的效果是一次自己造成的全面停機：VM、資料庫、函式、Kubernetes 叢集一起停擺，停損開關本身跑在同一個專案時也會停。Cloud Billing 文件另外警告，停用帳單時資源可能被永久刪除，也不保證服務能恢復，所以這是一次可能遺失資料的停機。判斷方式是比較兩種損失：「被濫用或程式出錯而多付一筆費用」與「這個專案的服務停止、資料可能遺失」，哪一種比較大。

判斷的單位是專案，因為停損開關停的是整個專案。混合了正式服務與沙箱的專案照正式服務判斷；想對沙箱建停損開關，就先把沙箱搬到自己的專案。逐個專案套下面三條：

• 停機時沒有人受影響、而且專案裡的資料都能從別處重建（只跑實驗的專案、個人的沙箱多半是這樣）：多付的費用沒有上限，建停損開關。
• 停機可以接受、而資料不能遺失（團隊共用的 staging、有持久資料的實驗專案）：建只停止花錢的資源的那一種。
• 停機會影響使用者或同事（正式服務）：全面停機的代價通常高於一段時間的超支，改用預算警示，寄到值班的人手上（見〈預算警示：門檻依據、範圍、抵免與通知對象〉的通知對象），並把〈費用失控的來源與反應時間〉列的即時限制設上，讓帳單資料延遲期間的花費有上限。沒有人能值班時，處理時間就是自己下一次看到通知的時間，配額要依這段時間能承受的花費來設。風險集中的功能可以拆出去，例如 API 金鑰寫在網頁或 App 裡、任何人都拿得到那把金鑰的功能：拆到自己的專案再對那個專案建停損開關。停損開關停掉那個專案時，正式服務裡用這把金鑰的功能也會一起停，正式服務的其餘部分與正式服務的資料要放在另一個專案。

接停損開關的預算要另外建、範圍限定在要停用的那一個專案，金額設成這個專案本期能承受的最高花費減掉帳單資料延遲期間多出的費用。延遲費用的上限約是「每小時最多能花的費用 × 延遲的時數」，每小時最多能花多少由〈費用失控的來源與反應時間〉列的配額決定，所以先把配額壓到實際需要的量，才估得出這個上限。一個主題只接一個預算：函式不分辨通知來自哪一個預算，好幾個預算送到同一個主題時，任何一個超支都會讓它停掉同一個專案。

停損開關有三項設定，任何一項設錯，部署指令都回報成功、函式狀態也都顯示 ACTIVE，停損開關卻不會解除帳單連結：服務帳號要另外有讀取帳單狀態的 roles/browser（roles/billing.projectManager 只能建立與刪除帳單連結）、部署要加 --retry（不加時，函式在中途拋出例外而 Cloud Run 回 200，那則超出預算的通知被確認收訊、不再重送）、觸發器的服務帳號要有呼叫函式的 roles/run.invoker（缺它時每一次推送都被 403 擋下，函式一次都不執行）。三項的指令與實測時看到的錯誤，在 GCP 預算警示與停損開關的實測紀錄 的〈建服務帳號並授予兩個角色〉〈部署函式：兩個服務帳號、執行個體上限與重試〉〈授予觸發器呼叫函式的權限〉。

停損開關放在另一個專案

專案裡跑的工作負載可能被入侵時，攻擊者拿到的身分若有專案的編輯權限，也能刪掉同一個專案裡的函式與主題。主題、函式與服務帳號可以放在一個專門放帳單工具、不受停用影響的專案（Cloud Billing 文件稱為 FinOps administration project，下文稱管理專案；文件建議把帳單相關的主題集中在這種專案），被保護的專案只綁服務帳號的兩個角色。這樣放有三個效果：解除連結之後函式仍在運作，能記錄並通知人「哪個專案被停了」；被保護的專案裡被入侵的身分刪不掉它；驗收時函式不會跟著停，所以兩則測試訊息不必照順序發。代價是管理專案成了所有停損開關的共同依賴：它的帳單停了或權限被收掉，所有被保護的專案一起失去停損開關，所以監看停損開關有沒有持續收到通知的心跳監看要放在管理專案以外。分開放時要改的指令在 GCP 預算警示與停損開關的實測紀錄 的〈停損開關放在另一個專案時要改的指令〉。

驗收：真實通知確認預算到 Pub/Sub 主題的一段，測試訊息確認主題之後的一段

停損開關平常不動作，壞掉與「還沒輪到它動作」在任何狀態欄上都長得一樣；〈由預算通知觸發的處置：解除帳單連結與只停止花錢的資源〉最後一段列的三項設定，實測時各自讓它在狀態顯示正常時失效過一次。所以部署成功不算完成，驗收看的是呼叫鏈最後一段的結果：專案的帳單狀態。這是平常不動作的防護機制的部署驗證的一個應用。

驗收分成兩段，因為測試訊息是從主題送進去的：主題之後的每一段（觸發器、呼叫權限、函式、角色、重試）都會被行使到，主題之前的那一段（預算的範圍、金額、抵免設定、發布到主題的權限）不會。主題之前的那一段，用第一則真實的預算通知確認：通知裡的 costAmount 對照帳單報表上這個專案本期的費用，接近 0 而報表不是，就是抵免設定或範圍設錯了。主題之後的那一段，用一則低於預算、一則超出預算的測試訊息確認，兩則走的是函式的兩條分支；只有超出預算那一則會行使解除連結要用到的兩個權限，結果看 billingEnabled 有沒有變成 false。

這次驗收會實際讓專案停擺。專案有停用之後不能遺失的資料時，改用拆開驗證：在可拋棄的專案上用一份換了名稱與主題的複本完整觸發一次，在正式專案上只用 Policy Troubleshooter 確認服務帳號的權限；拆開驗證仍沒有行使正式專案上那一次解除連結，驗收紀錄要寫明缺了這一段。部署之後別人調整了角色或鎖定了帳單連結時，部署的人不會知道要重驗，所以另設一個心跳監看（dead man’s switch）：函式的紀錄長時間沒有出現就通知，讓函式停止收到通知這件事本身也成為訊號。兩段的訊息、查詢指令、拆開驗證的複本與心跳監看的設法，在 GCP 預算警示與停損開關的實測紀錄 的〈兩段驗收：第一則真實通知，再發兩則測試訊息〉與〈心跳監看：函式停止收到通知時告警〉。

解除連結之後恢復服務的順序

實際因為超支而停用之後，costAmount 是本期累計值，整個預算期間都不會降回預算以下；只重新連結的話，下一則預算通知（一天會來好幾則）會讓函式再解除一次。恢復的順序依停用的原因而不同：

• 服務自己出錯：修好程式之後，先調高預算金額或刪掉函式，再重新連結。
• 資源被別人濫用：重新連結之前，把預算金額調成目前的 costAmount 加上清理期間能承受的金額，讓停損開關在攻擊者再開資源時仍會動作，又不會在清理途中被已經累計的花費再觸發一次；並先撤銷外洩的 API 金鑰與服務帳號金鑰。重新連結之後列出並刪除不屬於自己的資源，清單要在重新連結之後列：實測停用期間 gcloud compute routers list 回傳零筆，而重新連結之後 Cloud Router 仍在，所以停用期間的空清單不代表資源已經刪除。確認乾淨之後再把預算調回原本的金額。

指令與實測時資源在停用前後的狀態，在 GCP 預算警示與停損開關的實測紀錄 的〈超支停用之後的恢復〉。

延伸閱讀：逐步的實作、上限的理由、費用的歸因、防護機制的驗收與服務帳號的兩邊權限

• → GCP 預算警示與停損開關的實測紀錄：建預算、主題、服務帳號、函式與觸發器、兩段驗收、心跳監看與恢復的逐步指令、實跑結果，以及每一步漏掉或換一種做法時的結果
• → 開發環境成本控制：〈Per-team 成本上限〉說明給每個團隊與環境設上限的理由，本篇是那個上限在 GCP 上的執行方式
• → 成本監控與告警：收到預算警示之後，靠資源標記定位是哪個團隊的哪類資源在漲；停損開關解除連結之前，要依歸因的結果選定是哪一個專案
• → 平常不動作的防護機制的部署驗證：停損開關、稽核紀錄與告警共用的驗收方法，以及「部署成功、狀態正常」為什麼不算驗收
• → Service Account（服務帳號）：服務帳號的權限分成「它能做什麼」與「誰能以它的身分行事」兩邊，停損開關的角色與部署者的 serviceAccountUser 各屬一邊