谷歌雲賬戶代付賬單:如何利用GCP IAM角色與服務賬號(Service Account)實現最小權限原則

在雲計算的安全領域,有一句無數運維和架構師用公司資產、甚至用自己的年終獎換來的血淚教訓:「

在雲端,比沒有密碼更可怕的,是所有人都在用管理員密碼。

」

很多剛接觸 Google Cloud (GCP) 的朋友,為了圖省事,或者因為嫌排查權限報錯太麻煩,往往會直接給團隊裡的開發、甚至給運行在服務器里的某段腳本,無腦套上一個

Owner

(所有者)或者

Editor

(編輯者)角色。 這種做法就像是把你家大門的萬能鑰匙,隨手復刻了幾十把分發給保潔、快遞員和路人。 一旦某個開發的電腦被黑客釣魚,或者代碼里不小心把密鑰(Key)提交到了公開的 GitHub 倉庫,黑客就能在幾秒鐘內徹底接管你的整個谷歌雲賬戶,把你幾年的核心資產洗劫一空,甚至在後台瘋狂開幾百台高配機器去挖礦,留給你一張天價的扣費賬單。

在 GCP 的安全世界裡,死死守住大後方的核心防禦武器,叫

IAM(Identity and Access Management,身份與訪問控制)

。 而大廠級網絡安全的核心靈魂,就是堅決貫徹

「最小權限原則(Principle of Least Privilege)」

--只給正確的人或機器,在正確的時間,授予剛好夠完成工作的最小特權。

今天我們拒絕任何官方的說教套話,不背枯燥的條文。 直接從最硬核的實戰切入,手把手帶你理清 IAM、角色與服務賬號的底層邏輯,為你的雲端資產焊死一套高標準的現代化安全防線。

第一階段:深度拆解,GCP IAM 的「三維世界模型」

要在 GCP 里配對權限,你必須在腦子裡把 IAM 的物理運行模型徹底理清楚。 谷歌的 IAM 權限控制體系,本質上是由三個維度的元素相互組合、焊死綁定的:

你是誰？ (Members / Principals):也就是身份的持有者。 可以是公司員工的谷歌郵箱(如 [email protected]),也可以是一個邏輯組,或者我們後面要重點聊的服務賬號(Service Account)。

你能幹什麼? (Roles):也就是角色的集合。 角色是一堆具體權限(Permission)的「大禮包」。 比如,想看服務器列表,需要 compute.instances.list 權限;想重啟服務器,需要 compute.instances.start 權限。 谷歌把這些細碎的權限打包在一起,就變成了各種各樣的「角色

」。

你在哪裡乾? (Resources / Hierarchy):也就是資源層級。 這是 GCP 的一大優雅設計。 你可以把權限掛在整個「組織(Organization)」級別,也可以掛在某個特定的「項目(Project)」級別,甚至可以精準到某一個具體的「GCS 存儲桶(Bucket)」上。

核心安全內幕:權限是有向下繼承特性的。 如果你在組織級別給了某個員工 Owner 權限,那麼他在這家公司旗下的所有子項目、所有服務器、所有數據庫裡都是至高無上的神。 因此,大廠規範嚴禁在組織或項目高層濫發高級別角色。

第二階段:死磕核心,大廠嚴禁使用的「三大權限巨坑」

在配置之前,我們先來幫你的認知「排毒」。 以下這三種做法,在正規企業的安全審計裡是絕對的一票否決:

1. 濫用基本角色(Primitive Roles)

基本角色指的是老舊的

所有者

(所有者)、

Editor

(編輯者)、

Viewer

(查看者)。 這類角色屬於「粗放型」的古董。 Editor 幾乎能增刪改項目裡的任何東西(從改代碼到刪數據庫)。

規範解法:全面擁抱 預定義角色(Predefined Roles)。 需要管虛擬機的,只給 Compute Admin;只需要看日誌的,只給 Logging Viewer。 讓專業的人乾專業的事。

2. 機器使用個人憑證(User Credentials)

很多新手寫了一個自動化腳本,要在本地定時備份雲端數據庫。 為了讓腳本能運行,他直接在本地用自己的個人賬號運行了

Gcloud auth login

。

災難發生:一旦這個員工離職,公司註銷了他的郵箱,這個在生產環境跑了半年的備份腳本會瞬間因為權限失效而崩潰。

規範解法:人走人的道,機器走機器的橋。 所有需要和 GCP 交互的程序、代碼、第三方系統,必須一律使用服務賬號(Service Account)。

第三階段:實戰演練--用服務賬號(Service Account)打通無密鑰安全鍊

我們來模擬一個最標準的商業生產場景:你寫了一個 Python 後端程序,部署在 GCP 的

Compute Engine (GCE) 虛擬機

裡。 這個程序每天需要去

Cloud Storage (GCS) 存儲桶

里讀取用戶的頭像圖片,並且把運行日誌寫進

Cloud Logging(日

誌服務)

。

如果按照原始的做法,你需要去後台生成一個包含密碼的 JSON 密鑰文件(Key),然後下載下來塞進服務器的代碼包里。

但大廠安全規範告訴你:在雲端,凡是看得見的明文密碼文件,都是洩露的定時炸彈。

我們利用 GCP 原生的服務賬號與 IAM 綁定,實現真正的「零密鑰、高安全」上雲:

步驟 1:創建專屬機器身份(Service Account)

進入

GCP 管理主控台

，左上角導航菜單找到

「IAM 和管理(IAM & Admin)」 -> 「服務賬號(Service Accounts)」

。

點擊頂部的 「創建服務賬號」。

服務賬號名稱:起名叫 gce-web-app-runner。 它會自動生成一個形如 [email protected] 的專屬機器郵箱。

點擊創建並繼續。

步驟 2:精準灌注最小權限(IAM 綁定)

在同一個創建頁面中,系統會問你要給這個機器身份賦予什麼角色。 我們堅決不選 Editor,進行精準的權限切割:

點擊角色下拉菜單,搜索並選擇 「Storage Object Viewer(存儲對象查看者)」。 註:這個角色只允許讀取存儲桶里的文件,哪怕黑客控制了服務器,他也休想往你的存儲桶里注入木馬、或者把整個桶一鍵清空。

點擊「添加其他角色」,搜索並選擇 「Logs Writer(日誌寫入者)」。 註:只給寫入日誌的權限,不給查看其他系統日誌的權限。

點擊完成。

步驟 3:靈魂合體--把身份掛載給虛擬機

身份和權限都配好了,現在我們要讓那台跑著代碼的虛擬機「穿上這件衣服」。

來到 Compute Engine -> VM 實例 頁面,點擊你的 Web 服務器,點擊編輯。

往下翻,找到 「服務賬號(Service Account)」 配置項。

在下拉菜單里,把原本默認的 Default 服務賬號切掉,精準選中你剛才新建的 gce-web-app-runner。

順手把下方的「訪問權限範圍(Access Scopes)」修改為 「允許全面訪問所有 Cloud API(Allow full access to all cloud APIs)」。 架構師技術避坑內幕:這裡是無數新手最容易懵圈的地方。 GCP 早期利用

「訪問權限範圍(Scopes)」來控車,現在這種方式已經過時了。 新一代的規範是:在這裡開大綠燈(Full Access),而把真正的權限安全大閘完全移交給上面第二步的 IAM 角色去接管。

點擊保存,重啟實例。

奇蹟時刻:代碼內部的「無密鑰神技」

現在,你連進這台服務器,看一眼你的 Python 代碼。 你不需要在代碼里寫任何的

AWS_ACCESS_KEY

或者把谷歌的 JSON 密碼文件硬編碼在裡面。 你只需要直接調用谷歌官方的 SDK:

Python

From google.cloud import storage

# 注入靈魂:根本不需要傳任何密鑰參數,SDK 會自動去宿主機網卡里嗅探掛載的 Service Account 身份

Storage_client = storage.Client()

Bucket = storage_client.bucket("my-user-avatars")

Blob = bucket.blob("user_101.jpg")

# 絲滑讀取

Data = blob.download_as_bytes()

Print("數據無密讀取成功! ")

由於身份和權限在谷歌網絡底層完成了天然的閉環,你的生產環境代碼裡沒有任何明文密碼。 黑客就算把你的 Git 倉庫翻個底朝天,也休想偷走任何一丁點雲端主權的碎片。

第四階段:商業級運維的避坑血淚史與防線加固

這套無密鑰架構跑起來後,你的雲端資產安全系數已經超越了 95% 的作坊式團隊。 但作為首席安全官(CISO),你必須立刻下達行政命令,去焊死以下兩個容易引發重大安全事故的隱形大坑:

1. 堅決禁止手動生成「服務賬號密鑰(JSON Key)」

在服務賬號的詳情頁裡,有一個叫「密鑰(Keys)」的標籤頁,裡面允許你點擊「創建新密鑰」並下載一個 JSON 文件。

殘酷的現實:很多開發為了圖方便,在本地調試代碼時懶得配環境變量,直接生成了一個 JSON 密鑰鎖在自己電腦裡。 一旦他的電腦丟失、或者他在離職時把這個文件用微信私傳出去,公司的安全鐵絲網就直接被撕開了一個大口子。 並且這種手動生成的 Key 默認有效期長達數年,極難審計。

大廠防禦規範:通過組織策略(Organization Policy)從根本上禁止創建服務賬號密鑰。 * 如果開發在本地電腦上確實需要調試

,指導他們使用 gcloud auth application-default login 命令,通過他們個人的企業谷歌郵箱在本地臨時獲取動態短效憑證。 如果是跨雲調用(比如 AWS 的機器想連 GCP),採用 Workload Identity Federation(工作負載身份聯合),讓 AWS 用自家的 OIDC 令牌和 GCP 直接隔空對暗號,實現雙向無物理密鑰通信。

2. 擁抱「IAM 條件限制(IAM Conditions)」的降維打擊

傳統的權限一經授予,就是全天候 24 小時生效。 但如果你們公司遭遇了緊急線上故障,需要讓一個外包專家在今天下午臨時進去看一眼生產環境的數據庫,過了今天就把權限收回,怎麼辦?

原始做法:今天配上角色,下班時全靠腦子記著去把它刪掉。 萬一忘了,外包專家的賬號就成了永久的隱患。

高級規範配置:在 IAM 頁面授予角色時,順手點擊 「添加條件(Add Condition)」。 你可以寫一條極其精準的規則:「僅當時間在 2026-05-30 13:00 至 18:00 之間,且請求的來源 IP 是公司辦公室公網 IP 時,該用戶的權限才生效。」 只要時鐘一過 18 點,谷歌的網絡大腦會自動讓該用戶的通行證瞬間作廢。 定時熔斷,不留一絲後患。

總結

在 Google Cloud 玩轉最小權限管理規範,核心的工業級精髓其實就在於十六個字:

人走人道,機器掛載,杜絕明文,時效熔斷

。

雲端安全從來不是靠各種繁瑣的口頭規章制度去約束人性,而是要靠這套天衣無縫、下沉到雲原生底層的分布式 IAM 機製去形成物理降維隔離。 把主導權交給「最小權限原則」,在享受無密鑰通信帶來的極致開發爽快感的同時,讓你的整座雲端商業帝國在公網上穩如泰山。