這篇記錄把 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄（下文稱 IAP 實作文章）的三項設定（IAP 用的 network tag、OS Login、移除外部 IP）套到 MIG 與 GKE 上的實際操作。內容依操作的順序是：建一份帶這三項設定的新 instance template，先讓一台 VM 換成新版（canary）再讓整組更新；用 recreate-instances 重建一台壞掉的 VM、比對重建之後換掉的主機金鑰；template 本身寫錯時退回上一版；在 GKE 上建一個專門給節點除錯用的 namespace，用 kubectl debug node 查看節點；node pool 的 private nodes、network tag 與 OS Login；控制平面的 authorized networks，以及改連 DNS-based endpoint、關掉 IP 端點的兩步切換。每一步寫出這次的取值與實測結果，以及沒做或換一種做法時的結果；替代做法與沒做時的結果沒有另外標註的是這次實測看到的，照官方文件推出的寫出文件，推論的寫明沒有實跑。逐台設定為什麼在這兩種環境裡會消失、MIG 救援的取捨、GKE 的兩個存取面、kubectl debug node 的權限邊界，以及控制平面的 authorized networks、DNS-based endpoint 與 private endpoint 三種存取方式的差別，寫在 GCP 上由 MIG 與 GKE 管理的 VM 的管理存取（下文稱概念篇），這裡不重寫。

MIG 與 GKE 由 Terraform 這類 IaC 管理時，下面的 gcloud 修改要改寫在程式碼裡，CLI 上只執行 describe 這類讀取用的指令；這篇的指令在沒有 IaC 的環境照著執行，有 IaC 的環境把它們當成欄位對照。instance template 不能修改、又被 MIG 引用著，所以 IaC 改 template 時，取代的順序要另外設成先建新的再刪舊的（Terraform 是 name_prefix 搭配 lifecycle { create_before_destroy = true }），否則先刪舊 template 的那一步會因為它還在使用中而失敗；canary 對應 google_compute_instance_group_manager 的兩個 version 區塊。這一段是推論，這次沒有用 Terraform 實跑。

建新的 instance template：現行設定照抄，再加 tag、OS Login 與不配外部 IP

instance template 建立之後不能修改，instance-templates create 從預設值開始建、不沿用舊 template 的任何設定，所以先把現行 template 讀出來，逐項帶進新的那一份。這三項設定為什麼要寫進 template、不能在 VM 上逐台改，見概念篇〈autohealing、滾動更新與擴增後消失的逐台設定：network tag、OS Login metadata 與外部 IP〉。

 1# 讀出現行 template 的完整設定，新 template 要逐項帶上
 2gcloud compute instance-templates describe <current-template-name> --format=yaml
 3
 4# 建一份新的 instance template：現行設定照抄，再加上 IAP 用的 tag、啟用 OS Login、不配外部 IP
 5gcloud compute instance-templates create <new-template-name> \
 6  --machine-type=<machine-type> \
 7  --image-family=<image-family> --image-project=<image-project> \
 8  --boot-disk-size=<boot-disk-size> \
 9  --network=<network-name> --subnet=<subnet-name> --region=<region> \
10  --service-account=<service-account-email> --scopes=<scopes> \
11  --labels=<labels> \
12  --tags=<ssh-via-iap-tag> \
13  --metadata=enable-oslogin=TRUE \
14  --metadata-from-file=startup-script=<startup-script-file> \
15  --no-address
16
17# 比對新舊兩份的設定：差異只該是刻意改的 tag、enable-oslogin 與 accessConfigs
18diff <(gcloud compute instance-templates describe <current-template-name> --format="yaml(properties)") \
19     <(gcloud compute instance-templates describe <new-template-name> --format="yaml(properties)")

• <current-template-name>：MIG 目前用的 template，gcloud compute instance-groups managed describe <mig-name> --zone=<zone> 的 instanceTemplate 欄。
• <new-template-name>：新 template 的名稱，自己取；template 不能改名也不能改內容，常見的做法是名稱帶版本或日期。
• --machine-type、--image-family、--image-project、--boot-disk-size、--network、--subnet、--region、--service-account、--scopes、--labels、--metadata-from-file=startup-script=：照 describe 讀出來的值填，describe 裡還有其他欄位（額外的磁碟、GPU、其他 metadata 鍵）也要對應的旗標一起帶上。--region 是 --subnet 所在的 region。describe 的欄位與旗標不是一對一：映像在 disks[].initializeParams.sourceImage，值可能是一個特定映像的完整路徑，也可能是 .../images/family/<family> 這種 family 的路徑（實測：用 --image-family 建的 template 讀出來是 .../images/family/debian-12），兩種都可以原樣交給 --image=<sourceImage 的值>，取代 --image-family 與 --image-project；服務帳號在 serviceAccounts[].email，template 用的是 Compute Engine 預設服務帳號時這一欄顯示 default 而不是 email（實測），原樣寫成 --service-account=default，建出的 template 用的仍是同一個預設服務帳號；startup-script 在 metadata.items 裡 key: startup-script 的 value，先把它存成檔案再交給 --metadata-from-file；regional 的 template 讀取時 describe 要加 --region=<region>。
• --tags=<ssh-via-iap-tag>：與 IAP 規則的 --target-tags 相同的 tag。新 template 只帶這裡列出的 tag，所以現行 template 已經有的其他 tag（describe 輸出的 tags.items，例如負載平衡器健康檢查用的）要一起列進來，逗號分隔。
• --metadata=enable-oslogin=TRUE：讓這個 template 建出的 VM 都啟用 OS Login；專案層級已經啟用時可以省略。
• --no-address：不配外部 IP。先確認流量入口已經在負載平衡器上，gcloud compute backend-services list --format="table(name, backends[].group)" 的 backends 欄要有這個 MIG。這一點只能事先查：服務若是靠 VM 的外部 IP 對外，〈先讓一台 VM 換成新 template（canary），再讓整組更新〉換上新版的那一台只是收不到流量、不容易察覺，canary 這一步驗不出來，整組更新之後服務就斷了。出站改由 Cloud NAT 承接，所以 Cloud NAT 要在滾動更新之前建好。已經存在的 VM 在滾動更新把它換成新版時才失去外部 IP。

這次用 --service-account=default 建的新 template，與現行 template 的 properties 比對，只差刻意改的 tag、enable-oslogin 與 accessConfigs。

• 沒做時（漏帶 describe 裡的欄位）：漏掉的欄位回到預設值，常見的後果是 VM 換成預設的服務帳號而失去存取權限，或啟動腳本沒有執行（從 create 由預設值開始建這一點推論，這次沒有實跑）；上面的 diff 會把漏掉的欄位列出來。
• 替代做法：
  • 用 gcloud compute instance-templates create <new-template-name> --source-instance=<instance-name> --source-instance-zone=<zone> 從一台現有的 VM 產生 template，換到的是不必逐項抄旗標；付出的是這條指令只能另外覆寫磁碟的定義，tag、OS Login 與 --no-address 要再以它為基礎建第二份，而來源 VM 有靜態外部 IP 時，那個位址會被抄進 template（Compute Engine〈Create instance templates〉，這次沒有實跑）。
  • 在專案層級設 enable-oslogin=TRUE、不寫進 template，換到的是 template 少一個鍵，付出的是 template 的行為依賴專案的設定，搬到別的專案就變了（推論，這次沒有實跑）。

先讓一台 VM 換成新 template（canary），再讓整組更新

1# 先讓一台 VM 用新 template（canary），其餘維持現行 template
2gcloud compute instance-groups managed rolling-action start-update <mig-name> \
3  --version=template=<current-template-name> \
4  --canary-version=template=<new-template-name>,target-size=1 \
5  --zone=<zone>
6
7# 那一台驗證通過之後，讓整組換成新 template
8gcloud compute instance-groups managed rolling-action start-update <mig-name> \
9  --version=template=<new-template-name> --zone=<zone>

• --version=template=：canary 那一行放現行的 template，代表其餘 VM 維持原狀；整組更新那一行放新的 template。兩行的 --version 放的 template 相反。
• --canary-version=template=<new-template-name>,target-size=1：讓一台 VM 換成新 template；target-size 也可以寫百分比（10%），條件是 MIG 有 10 台以上（Compute Engine〈Rolling out updates〉）。
• <mig-name>、--zone：MIG 的名稱與所在 zone，gcloud compute instance-groups managed list 查得到；regional MIG 把 --zone 換成 --region。

start-update 送出之後 MIG 在背景替換 VM，指令本身不等它完成。用下面兩條確認替換做完、並找出 canary 那一台：

1# 等到每台 VM 都換成指定的版本才返回
2gcloud compute instance-groups managed wait-until <mig-name> --version-target-reached --zone=<zone>
3
4# 列出 MIG 裡的 VM 與各自用的 template，INSTANCE_TEMPLATE 欄是新 template 的那一台就是 canary
5gcloud compute instance-groups managed list-instances <mig-name> --zone=<zone>

實測 wait-until 在替換做完之後才返回，list-instances 的 INSTANCE_TEMPLATE 欄只有一台是新 template。找到 canary 那一台之後，經由 IAP 連進去，確認 OS Login 登得進去、出站經過 Cloud NAT（驗證方式見 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈建 Cloud NAT 並移除外部 IP〉）。整組更新之後同樣用 wait-until 等它完成。

• 沒做時（不經過 canary、直接整組更新）：template 的 tag 或 OS Login 寫錯時，整組 VM 一起連不上（照滾動更新的作用推論，這次沒有實跑）。
• 替代做法：
  • 只改 tag 與 metadata 時加 --minimal-action=refresh：Compute Engine〈Rolling out updates〉寫明 refresh 不停止 VM，可以套用 metadata、labels、tags 這類項目，換到的是 VM 不重建、主機金鑰不變；付出的是 --no-address 移除外部 IP 不在那份清單上，很可能仍要重建（照官方文件推出，這次沒有實跑）。
  • --type=opportunistic 只在 VM 重建或擴增時才套用新 template，換到的是不主動中斷任何一台，付出的是組內新舊混雜，舊的 VM 一直沒有新的 tag（照官方文件推出，這次沒有實跑）。
  • 整組更新時加 --max-surge=1 --max-unavailable=0，每一批先多建一台新的、再刪一台舊的（實測先建後刪），換到的是更新期間可用台數不減少，付出的是多一台 VM 的費用，而且這兩個旗標只控制速度，更新仍會把整組換完。regional MIG 的 --max-surge 用固定數字時，GCP 只接受 0 或不小於 zone 數的值，錯誤訊息是 has to be either 0 or at least equal to the number of zones，所以分布在兩個以上 zone 的 regional MIG，--max-surge=1 會被拒絕。

重建一台壞掉的 VM：recreate-instances 與重建之後的主機金鑰

一台 VM 連不上、而原因是那台 VM 自己壞了（sshd 設定改壞、磁碟滿），讓 MIG 依 template 重建它：

1# 依 template 重建一台 VM：開機磁碟換成依 MIG 目前的版本設定新建的一顆，VM 重新開機
2gcloud compute instance-groups managed recreate-instances <mig-name> \
3  --instances=<instance-name> --zone=<zone>

<instance-name> 是要重建的那台 VM，gcloud compute instance-groups managed list-instances <mig-name> --zone=<zone> 列出 MIG 裡的 VM。實測重建在稽核紀錄裡是一次 instances.update（沒有 delete 與第二次 insert），VM 沿用原本的名稱與執行個體 ID，gcloud compute instances describe 的建立時間也不變，所以確認重建做完要看開機磁碟：MIG 建的 VM 開機磁碟預設與 VM 同名，gcloud compute disks describe <instance-name> --zone=<zone> --format="value(creationTimestamp)" 印出的時間落在重建的那一刻，就代表磁碟已經換新。canary 期間重建的 VM 用哪一版，由 MIG 依兩個版本各自的 target-size 分配，實測重建的那一台沿用了原版本。

重建之後第一次 gcloud compute ssh 出現 WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 並拒絕連線（實測），原因與這個警告為什麼不能直接略過，見 GCP 上由 MIG 與 GKE 管理的 VM 的管理存取 的〈MIG 的救援：重建、退回舊版 template 與 Serial Console 各自適用的情形〉。比對的來源是 VM 回報到 guest attributes 的主機金鑰，專案或 template 的 metadata 要事先設了 enable-guest-attributes=TRUE（專案層用 gcloud compute project-info add-metadata --metadata enable-guest-attributes=TRUE）：

1# 讀出 VM 回報的 ED25519 主機金鑰指紋，與警告訊息裡 "The fingerprint for the ED25519 key sent by the remote host is" 下一行的 SHA256 值比對
2gcloud compute instances get-guest-attributes <instance-name> --zone=<zone> \
3  --query-path=hostkeys/ssh-ed25519 --format="value(value)" \
4  | awk '{print "ssh-ed25519 " $1}' | ssh-keygen -lf -
5
6# 兩個指紋相同之後，移除這台 VM 的舊紀錄，再用 gcloud compute ssh 連線
7ssh-keygen -R compute.<instance-id> -f ~/.ssh/google_compute_known_hosts

<instance-id> 是 gcloud compute instances describe <instance-name> --zone=<zone> --format="value(id)" 印出的數字。ssh-keygen -R 會把原本的檔案備份成同目錄的 google_compute_known_hosts.old。實測啟用 guest attributes 之後，gcloud 不會自動更新已經存在的 known_hosts 紀錄，讀出的 ED25519 指紋與警告裡的一致，移除舊紀錄之後即可連線。兩個指紋不同時不要移除，先確認連到的 IP 仍是這台 VM 的位址，以及連線是否經過了 IAP 以外的代理；兩項都正常而指紋仍不同時，改從 Serial Console 登入 VM、讀 /etc/ssh/ssh_host_ed25519_key.pub 的指紋再比一次。警告寫的是 ECDSA 時，指令裡的 ED25519 與 ssh-ed25519 分別換成 ECDSA 與 ecdsa-sha2-nistp256。

• 沒做時（不設 enable-guest-attributes）：重建之後沒有不經過這條 SSH 連線的地方可以比對主機金鑰，只剩從 Serial Console 登入讀指紋，或不比對就移除舊紀錄；不比對就移除，等於關掉主機金鑰檢查（推論，這次沒有實跑）。
• 替代做法：
  • 從 Serial Console 登入修那台 VM，換到的是保留現場，付出的是要事先在映像檔裡放救援帳號（救援帳號的密碼雜湊寫在映像檔裡，不寫進 template 的 startup-script，理由與共用密碼雜湊的代價見概念篇〈MIG 的救援：重建、退回舊版 template 與 Serial Console 各自適用的情形〉）；登入與 sudo 的做法見 IAP 實作文章的〈準備救援入口：Serial Console 與本機救援帳號〉。
  • VM 上有不能丟的狀態時，MIG 的 stateful 設定（stateful policy 或 per-instance config）把指定的磁碟、IP 與 metadata 標為要保留，recreate-instances 重建時會沿用它們（Compute Engine〈Stateful MIGs〉，這次沒有實跑）。

template 本身寫錯時退回上一版

重建修不好的是 template 本身的錯：新版 template 的 tag 寫錯、啟動腳本有錯，重建出來的每一台都一樣壞。這種錯要退回上一版 template，所以舊版 template 留到新版驗證完之後再刪：

1# 退回上一版 template：整組換回舊版；canary 期間執行時，只有 canary 那幾台被換回
2gcloud compute instance-groups managed rolling-action start-update <mig-name> \
3  --version=template=<previous-template-name> --zone=<zone>

<previous-template-name> 是新版之前那一份 template 的名稱，gcloud compute instance-templates list 列得出來。這次實測退回成功。Compute Engine〈Rolling out updates〉寫明沒有專門的退回指令，退回就是送一次指向舊 template 的更新。

• 沒做時（新版一驗證就刪掉舊 template）：退回時要用 describe 讀過的舊設定重建一份 template，而舊 template 已經刪掉、讀不到了（從 template 不能修改、刪了就沒有這兩點推論，這次沒有實跑）。

GKE 節點除錯：建專用的 namespace，用 kubectl debug node 查看節點

節點除錯集中在一個刻意保留為 privileged 等級、只有維運群組能建 Pod 的 namespace，由叢集管理員事先建好：

1# 建一個專門給節點除錯用的 namespace，並允許特權 Pod
2kubectl create namespace <namespace>
3kubectl label namespace <namespace> pod-security.kubernetes.io/enforce=privileged

<namespace> 自己取，例如 node-debug；建好之後只把 GCP 上由 MIG 與 GKE 管理的 VM 的管理存取 的〈kubectl debug node 的權限邊界：RBAC 與 Pod Security Admission〉列的那組 pods 與 pods/attach 權限綁給維運群組。接著在這個 namespace 裡對節點開除錯 Pod：

1# 在指定節點上開一個除錯用的 Pod，節點的根目錄掛在 /host
2kubectl debug node/<node-name> -it --image=ubuntu --profile=sysadmin --namespace=<namespace>
3
4# 進到 Pod 之後，切換到節點的根目錄，像登入節點一樣查看
5chroot /host

• <node-name>：節點名稱，kubectl get nodes 的第一欄。
• --image=ubuntu：除錯 Pod 用的映像檔，換成組織允許、帶著除錯工具的映像檔。
• --profile=sysadmin：讓除錯 Pod 以特權容器（privileged container）執行，多給的是需要額外 Linux capability 的操作，例如用 nsenter 進入節點 PID 1 的 namespace、掛載檔案系統；只查看檔案與 log 時，預設的 general profile 就夠了（kubectl debug --help 的 --profile 說明寫著預設值）。
• --namespace=<namespace>：除錯 Pod 建在上面建好的那個 namespace；不給時落在 kubeconfig 目前設定的 namespace（通常是 default）。

這個 Pod 用完不會自動刪除，結束後用 kubectl delete pod <debug-pod-name> --namespace=<namespace> 刪掉（kubectl get pods --namespace=<namespace> 找名稱以 node-debugger- 開頭的那一個）。實測 GKE 上未設 label 的 default 接受除錯 Pod、設了 baseline 的 namespace 拒絕；kind 上 privileged 的 namespace 接受。

• 沒做時（不建專用 namespace）：沒有設 Pod Security label 的 namespace（包括 default）在 GKE Standard 上接受特權 Pod，任何能在 default 建 Pod 的帳號都能用這個方法以 root 操作節點。少了 list 或 watch 權限時，Pod 已經建好而 kubectl 停在等待、反覆印出 cannot list resource "pods"；少了 pods/attach 時 Pod 建得出來卻進不去；兩種都會留下一個在跑的除錯 Pod，要用 kubectl delete pod 刪掉（kind 上實跑）。
• 替代做法：
  • 用 --profile=baseline 或 restricted，換到的是建得進 baseline 以上的 namespace，付出的是看不到節點的檔案。
  • 查節點層的狀況先看 Cloud Logging 裡的節點紀錄，換到的是不必在節點上開任何 Pod，付出的是只看得到已經送進 Logging 的紀錄（推論，這次沒有實跑）。GKE Autopilot 預設拒絕特權 Pod，也不提供節點 SSH，只剩這一條（GKE〈Autopilot overview〉，這次沒有實跑）。

node pool：private nodes、network tag 與 OS Login

節點仍要 SSH 時（GKE Standard），把 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的三項設定搬到 node pool 上：

1# 既有 node pool 改成節點只有內部 IP（GKE 依升級策略逐批重建節點）
2gcloud container node-pools update <pool-name> --cluster=<cluster-name> --location=<location> --enable-private-nodes
3
4# 讀出現有的 tag，再用整份清單設定（這個指令整組取代使用者設定的 tag）
5gcloud container node-pools describe <pool-name> --cluster=<cluster-name> --location=<location> --format="value(config.tags)"
6gcloud container node-pools update <pool-name> --cluster=<cluster-name> --location=<location> --tags=<tag1>,<tag2>

• <pool-name>、<cluster-name>：gcloud container node-pools list --cluster=<cluster-name> --location=<location> 與 gcloud container clusters list 查得到。<location> 是叢集所在的 zone 或 region。
• --enable-private-nodes：先確認節點所在 subnet 的 region 已經有 Cloud NAT，換成內部 IP 之後節點的出站都經過它；沒有它時節點拉不到外部 registry 的映像，工作負載起不來。GKE 依 node pool 的升級策略逐批重建節點，所以排在可以承受節點輪替的時段做。新叢集在 gcloud container clusters create 加 --enable-private-nodes 作為整個叢集的預設。實測既有 node pool 的這項變更重建了節點，出站走 Cloud NAT、tag 保留。
• --tags=<tag1>,<tag2>：實測整組取代（gcloud 的確認提示也這樣寫），GKE 自動建立的防火牆規則用的 tag 保留，節點沒有重建。

OS Login 的授權方式同單台 VM，見 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 的〈啟用 OS Login：先授角色、單台先行、再做專案層級〉。專案層級的 enable-oslogin=TRUE 是否套用到 GKE Standard 的節點，GKE 自己的兩份文件寫法相反，所以啟用之後經由 IAP 實際登入一個節點確認：登入後執行 whoami，看到的是由 Google 帳號 email 轉換而來的 OS Login 帳號，才表示這個 node pool 的節點套用了 OS Login；看到的是 metadata 金鑰對應的本機帳號，代表節點沒有套用，SSH 仍由 metadata 金鑰控制。這次在 1.36.4-gke 的節點上看到的是 OS Login 帳號，這是單一版本的觀察。

• 沒做時（只在單一節點上 add-tags）：節點升級或自動修復重建之後 tag 消失，IAP 規則套不到它（照概念篇〈autohealing、滾動更新與擴增後消失的逐台設定：network tag、OS Login metadata 與外部 IP〉的機制推論，這次沒有實跑）。
• 替代做法：不開節點 SSH、只用 kubectl debug node，換到的是不必維護節點的 tag、OS Login 與 IAP 規則，付出的是能建除錯 Pod 的帳號就等於節點的 root，權限邊界移到 RBAC 與 Pod Security Admission。

控制平面：authorized networks，或改連 DNS-based endpoint 再關掉 IP 端點

 1# authorized networks：只放行列出的來源 IP 範圍連到控制平面的 IP 端點
 2gcloud container clusters update <cluster-name> --location=<location> \
 3  --enable-master-authorized-networks --master-authorized-networks=<cidr1>,<cidr2>
 4
 5# DNS-based endpoint 的啟用：IP 端點仍然開著
 6gcloud container clusters update <cluster-name> --location=<location> \
 7  --enable-dns-access
 8
 9# 關掉 IP 端點：每個人與每條 CI 都改連網域名稱端點之後才執行
10gcloud container clusters update <cluster-name> --location=<location> \
11  --no-enable-ip-access

• <cidr1>,<cidr2>：允許的來源 IP 範圍，CIDR 格式，單一個 IP 寫成 /32。實測以 Private Service Connect 建立的叢集拒絕文件範例用的保留網段 203.0.113.0/24，錯誤訊息寫明只接受在網際網路上可路由的範圍。--master-authorized-networks 每次都整組取代舊清單，執行這條指令的人與 CI 的出口 IP 要列在裡面：實測漏列時指令一生效 kubectl 就逾時，gcloud 不經過這個端點，用同一條指令改回清單就恢復。
• --enable-dns-access 與 --no-enable-ip-access 分成兩次執行：寫在同一條指令裡會在啟用的同時關掉 IP 端點，還在用 IP 端點的人與 CI 當場連不上。--no-enable-ip-access 關掉的是公開與內部兩個 IP 端點，VPC 內用內部 IP 連 API server 的跳板機、自架 runner 與 Terraform 也在要改的範圍內。

改連 DNS-based endpoint 時，每個人在本機執行 gcloud container clusters get-credentials <cluster-name> --location=<location> --dns-endpoint，讓 kubeconfig 指向那個網域名稱。確認有沒有改連：每個人與每條 CI 用的 kubeconfig，kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}' 輸出的是網域名稱而不是 IP。DNS-based endpoint 預設只接受 Google 的 IAM 憑證，CI 或工具若用 kubeconfig 裡靜態的 Kubernetes ServiceAccount token 或 client certificate，要另外在 clusters update 加 --enable-k8s-tokens-via-dns 或 --enable-k8s-certs-via-dns。

實測：DNS endpoint 的兩步切換不受 IP 清單限制；--no-enable-ip-access 之後 IP 端點逾時（對照組：開啟且來源在清單內時 HTTP 401），DNS 照常；clusters update --enable-ip-access 恢復。用第二個帳號以 --token 帶入它的 access token：沒有 IAM 角色時 DNS endpoint 回 Google 前端的 403 HTML；只有 roles/container.clusterViewer 時進到 API server，列節點回 cannot list resource "nodes"，訊息裡寫著它要的 IAM 權限 container.nodes.list。

• 沒做時（維持公開端點、不設任何限制）：任何地方都連得到 API server，只靠 Kubernetes 的認證與 RBAC 擋下沒有權限的請求，等於網路可達性全開（照 GKE〈Access the control plane〉推出，這次沒有在公開端點上量）。
• 替代做法：
  • authorized networks 換到的是設定一條指令，付出的是 IP 會變動時要一直改、分辨不出個人；設了之後，GCP 上其他客戶的外部 IP 是否放行由 --enable-google-cloud-access／--no-enable-google-cloud-access 決定。實測沒碰過這兩個旗標時，describe 沒有 gcpPublicCidrsAccessEnabled 欄位，這時實際是否放行沒有驗證；變更可能要幾個小時才生效（GKE 文件，這次沒有實跑）。
  • private endpoint（--enable-private-endpoint）換到的是控制平面只剩內部 IP，付出的是從 VPC 外管理時要經過 VPN 或跳板機（GKE 文件，這次沒有實跑）。三種端點的比較見概念篇〈GKE 控制平面的存取：authorized networks、DNS-based endpoint 與 private endpoint〉。

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 設定要寫回程式碼