員工身分聯盟

本文說明員工身分聯盟的重要概念。

什麼是員工身分聯盟?

員工身分聯盟可讓您使用外部識別資訊提供者 (IdP),透過 IAM 驗證工作團隊 (例如員工、合作夥伴和約聘人員等使用者群組) 並授權,讓使用者存取 Google Cloud 服務。使用員工身分聯盟時,您不需要像使用 Cloud Identity 的 Google Cloud Directory Sync (GCDS) 一樣,將現有 IdP 的使用者身分與身分識別資訊同步處理。 Google Cloud員工身分聯盟擴充了 Google Cloud身分識別功能,支援無須同步處理的屬性型單一登入。

使用者通過驗證後,系統會根據從 IdP 收到的資訊,判斷 Google Cloud 資源的存取範圍。

您可以將員工身分聯盟與支援 OpenID Connect (OIDC)SAML 2.0 的任何 IdP 搭配使用,例如 Microsoft Entra ID、Active Directory Federation Services (AD FS) 和 Okta 等。

工作團隊身分集區

透過員工身分集區,您可以管理員工身分群組和這些身分的 Google Cloud 資源存取權。

您可以透過集區執行下列操作:

  • 將使用者身分分組,例如 employeespartners
  • 將 IAM 存取權授予整個集區或部分集區。
  • 連結一或多個 IdP 的身分。
  • 為需要類似存取權限的一群使用者定義政策。
  • 指定 IdP 專屬設定資訊,包括屬性對應屬性條件
  • 為第三方身分啟用 Google Cloud CLI 和 API 存取權。
  • 將集區內使用者存取權記錄至 Cloud 稽核記錄,並附上集區 ID。

您可以建立多個集區。如需這類方法的範例,請參閱「範例:多個工作團隊身分池」。

集區是在Google Cloud 機構層級設定。 因此,只要您擁有適當的 IAM 權限來查看集區,就能在機構內的所有專案和資料夾中使用集區。首次為機構設定員工身分聯盟時,您會提供集區名稱。在 IAM 允許政策中,您會依名稱參照集區。因此,建議您為集區命名,清楚說明其中包含的身分。

工作團隊身分集區提供者

工作團隊身分集區提供者是一個實體,會說明您的 Google Cloud 機構和 IdP 之間的關係。

員工身分聯盟遵循 OAuth 2.0 權杖交換規格 (RFC 8693)。 您將外部身分識別供應商的憑證提供給安全權杖服務,該服務會驗證憑證中的身分,然後傳回短期存取權杖做為交換。 Google Cloud

OIDC 流程類型

對於 OIDC 提供者,員工身分聯盟同時支援授權碼流程隱含流程。一般認為授權碼流程的安全性最高,因為使用者完成驗證後,權杖會透過獨立的安全後端交易,直接從 IdP 傳回至 Google Cloud。因此,程式碼流程交易可以擷取任何大小的權杖,讓您有更多可用的聲明,用於屬性對應和屬性條件。相較之下,在隱含流程中,ID 權杖會從 IdP 傳回瀏覽器。權杖會受到個別瀏覽器網址大小限制。

Google Cloud 員工身分聯盟控制台

員工身分集區中的使用者可以存取員工身分聯盟控制台,也就是控制台 (聯合) Google Cloud 。這些使用者可透過控制台的 UI 存取Google Cloud 支援員工身分聯盟的產品

屬性

您的 IdP 會提供屬性,部分 IdP 稱為「聲明」。屬性包含使用者的相關資訊。您可以在屬性對應屬性條件中使用這些屬性。

屬性對應

您可以使用 Google Cloud 一般運算語言 (CEL) 對應這些屬性。

本節說明Google Cloud 提供的必要和選用屬性。

您也可以在 IdP 中定義自訂屬性,然後供特定 Google Cloud 產品使用,例如 IAM 允許政策。

屬性對應的大小上限為 16 KB。如果屬性對應的大小超過 16 KB 的限制,登入嘗試就會失敗。

屬性如下:

  • google.subject (必要):驗證使用者的專屬 ID。這通常是 JWT 的主體聲明,因為 Cloud Audit Logs 記錄會將這個欄位的內容記錄為主體。您可以使用這個欄位,為授權決策設定 IAM。建議您不要使用可變更的值,因為如果變更 IdP 使用者目錄中的值,使用者就會失去存取權。

    長度上限為 127 個位元組。

  • google.groups (選用):驗證使用者所屬的群組集合。您可以使用部分 CEL 設定邏輯運算式,產生字串陣列。您也可以使用這個欄位,為授權決策設定 IAM。google.groups 的限制如下:

    • 建議群組名稱長度不要超過 40 個字元。

    • 如果單一使用者屬於超過 400 個群組,該使用者的登入嘗試就會失敗。為解決這個問題,您必須在聲明中定義較小的群組集,並只對應用於將使用者連結至Google Cloud的群組。

    • 如果您使用這項屬性在 IAM 中授予存取權,系統會為對應群組中的每位成員授予存取權。因此,建議您確保只有貴機構的授權使用者可以修改對應群組的成員資格。

  • google.display_name (選用):用於在 Google Cloud 控制台中設定登入使用者名稱的屬性。這項屬性無法用於 IAM 允許政策,也無法用於屬性條件。

    長度上限為 100 個位元組。

  • google.profile_photo (選用):使用者縮圖相片的網址。 建議使用 400x400 像素的相片,設定這個屬性後,圖片就會顯示為使用者在 Google Cloud 控制台中的個人資料相片。如果未設定這個值或無法擷取,系統會改為顯示一般使用者圖示。這個屬性無法用於 IAM 允許政策或屬性條件。

  • google.posix_username (選用):符合 POSIX 規範的專屬使用者名稱字串,可用於下列用途:

    這項屬性無法用於 IAM 允許政策或屬性條件。長度上限為 32 個字元。

  • google.email (選用):用於將 IdP 中已登入的聯盟使用者電子郵件地址,對應至您透過員工身分聯盟 OAuth 用戶端整合整合的產品。這項屬性無法用於 IAM 允許政策或屬性條件。

    舉例來說,如要使用 OIDC 協定對應 Okta 的電子郵件地址,請在屬性對應中加入 google.email=assertion.email

    支援 OAuth 用戶端整合的產品範例如下: Google Cloud

  • attribute.KEY (選用):外部 IdP 定義的屬性,存在於使用者的 IdP 權杖中。您可以在 IAM 允許政策中使用自訂屬性,定義授權策略。

    舉例來說,您可以在 IdP 中選擇定義屬性,例如將使用者的成本中心定義為 costcenter = "1234",然後以下列方式參照主體:

    principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workforcePools/WORKFORCE_POOL_ID/attribute.costcenter/1234
    

    將 Google Cloud 資源存取權授予這個主體 ID 後,IdP 中設定為將 costcenter 屬性設為 1234 的所有身分,都能存取這些資源。

    最多可設定 50 項自訂屬性對應規則。每項規則的大小上限為 2048 個字元。

    雖然我們未限制您在此對應的屬性,但強烈建議您選擇值穩定的屬性。舉例來說,attribute.job_description 等屬性可能會因多種原因而變更 (例如提升可讀性)。建議您改用 attribute.role。後者的變更表示指派的責任有所變更,並與授予使用者的存取權變更一致。

你可以使用標準 CEL 函式轉換屬性值。您也可以使用下列自訂函式:

  • split 函式會根據提供的分隔符值分割字串。舉例來說,如要從電子郵件地址屬性擷取 username 屬性,請在 @ 分割值並使用第一個字串,然後使用下列屬性對應:

    attribute.username=assertion.email.split("@")[0]
    

  • join 函式會根據提供的分隔符值,合併字串清單。舉例來說,如要透過串連字串清單並以 . 做為分隔符號,填入自訂屬性 department,請使用下列屬性對應:

    attribute.department=assertion.department.join(".")
    

屬性條件

屬性條件是選用的 CEL 運算式,可讓您對 Google Cloud 接受的身分屬性設定限制。

使用屬性條件的好處包括:

  • 您可以使用屬性條件,只允許部分外部身分驗證 Google Cloud 專案。舉例來說,您可能只想允許特定團隊中的身分登入,尤其是在使用公開 IdP 時。舉例來說,您可能想允許會計團隊登入,但不允許工程團隊登入。
  • 屬性條件可防止用於其他平台的憑證用於 Google Cloud,反之亦然。這有助於避免混淆副手問題

與 GitHub 或其他多租戶身分識別提供者聯合時,請使用屬性條件

員工身分聯盟不會維護使用者帳戶目錄,而是實作以聲明為準的身分。因此,如果兩個權杖是由同一個身分提供者 (IdP) 發出,且其聲明對應至相同google.subject值,系統就會假設這兩個權杖識別的是同一位使用者。如要瞭解是哪個 IdP 核發權杖,員工身分聯盟會檢查並驗證權杖的核發者網址。

GitHub 和 Terraform Cloud 等多租戶 IdP 會在所有租戶中使用單一簽發者網址。對於這些供應商,簽發者網址會識別所有 GitHub 或 Terraform Cloud,而非特定 GitHub 或 Terraform Cloud 機構。

使用這些身分提供者時,光是讓 Workforce Identity Federation 檢查權杖的簽發者網址,無法確保權杖來自可信來源,且其聲明可信。如果多租戶 IdP 只有一個發行者網址,建議您使用屬性條件,確保只有正確的租戶可以存取。

在 IAM 政策中代表工作團隊集區使用者

下表列出您用來將角色授予單一使用者、使用者群組、具有特定聲明的使用者,或工作人員集區中所有使用者的主體 ID。

身分 ID 格式
員工身分集區中的單一身分 principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
群組中的所有員工身分 principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID
具有特定屬性值的所有員工身分 principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE
員工身分集區中的所有身分 principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*

如需完整的主體 ID 清單,請參閱「主體 ID」。

詳細的稽核記錄

詳細的稽核記錄是員工身分聯盟的功能,可將從 IdP 收到的屬性記錄至 Cloud 稽核記錄。

建立員工身分集區供應商時,可以啟用詳細稽核記錄。

如要瞭解如何透過詳細稽核記錄排解屬性對應錯誤,請參閱一般屬性對應錯誤

JSON 網路金鑰

工作團隊集區供應商可以存取 IdP 在 jwks_uri 欄位中提供的 JSON Web 金鑰 (JWK),位於 /.well-known/openid-configuration 文件中。如果 OIDC 供應商未提供這項資訊,或發行者無法公開存取,您可以在建立或更新 OIDC 供應商時,手動上傳 JWK。

限制跨機構存取權

工作團隊身分集區主體無法直接存取所屬機構以外的資源。不過,如果主體獲准在機構內模擬服務帳戶,則可略過這項限制,因為服務帳戶不會受到同等限制。

工作團隊集區使用者專案

大多數 Google Cloud API 會將帳單和配額用量計入專案,而該專案包含 API 要求存取的資源。這些 API 稱為資源型 API。部分 Google Cloud API 會向與用戶端相關聯的專案收費,這類 API 稱為以用戶端為準的 API。用於帳單和配額的專案稱為「配額專案」

建立員工身分聯盟設定檔時,請指定工作團隊集區使用者專案。這個專案用於向應用程式呼叫的 Google API 識別應用程式。除非使用 gcloud CLI 啟動 API 要求,否則工作站集區使用者專案也會做為以用戶端為基礎的 API 預設配額專案。您必須擁有指定專案的 serviceusage.services.use 權限,這項權限包含在服務使用情形消費者 (roles/serviceusage.serviceUsageConsumer) 角色中。

如要進一步瞭解配額專案、以資源為準的 API 和以用戶端為準的 API,請參閱「配額專案總覽」。

範例:多個工作團隊身分集區

本節提供範例,說明多個集區的典型用法。

您可以為員工建立一個集區,為合作夥伴建立另一個集區。跨國機構可能會為機構內的不同部門建立個別的集區。集區可進行分散式管理,不同群組可獨立管理特定集區,且只有集區中的身分可獲得角色。

舉例來說,假設名為「Enterprise Example Organization」的公司與名為「Partner Example Organization Inc」的公司簽約,由後者提供 Google Kubernetes Engine (GKE) DevOps 服務。如要讓合作夥伴範例機構的員工提供服務,必須允許他們存取企業範例機構的 Google Kubernetes Engine (GKE) 和其他 Google Cloud 資源。Enterprise Example 機構已有名為 enterprise-example-organization-employees 的工作團隊身分集區。

如要允許 Partner Example Organization 管理 Enterprise Example Organization 資源的存取權,Enterprise Example Organization 會為 Partner Example Organization 員工使用者建立獨立的員工集區,方便 Partner Example Organization 管理。Enterprise Example Organization 會將工作團隊集區提供給 Partner Example Organization 管理員。合作夥伴範例機構的管理員使用自己的 IdP 授予員工存取權。

如要完成這項操作,企業範例機構的管理員須執行下列工作:

  1. 在 Enterprise Example Organization 的 IdP 中,為 Partner Example Organization 管理員建立身分,例如 partner-organization-admin@example.com。這個 IdP 已在名為 enterprise-example-organization-employees 的集區中設定。

  2. 建立名為 example-organization-partner 的新工作團隊集區。

  3. example-organization-partner 集區建立下列允許政策:

    {
      "bindings": [
        {
          "role": "roles/iam.workforcePoolEditor",
          "members": [
            "principalSet://iam.googleapis.com/locations/global/workforcePools/enterprise-example-organization-employees/subject/partner-organization-admin@example.com"
          ]
        }
      ]
    }
    
  4. 在 Enterprise Example Organization 的機構中,為 example-organization-partner 集區授予資源角色,讓使用者存取所需資源。

合作夥伴範例機構的管理員現在可以設定 example-organization-partner 集區,與 IdP 建立連線。然後允許合作夥伴範例機構的工作人員使用合作夥伴範例機構的 IdP 憑證登入。登入後,合作夥伴範例機構的員工使用者即可存取 Google Cloud 資源,但會受到企業範例機構定義的政策限制。

更輕鬆管理存取權

在大型企業中,IT 管理員通常會建立安全群組,做為存取控制最佳做法模型的一部分。安全性群組可控管內部資源的存取權。此外,公司通常會為員工建立其他群組,並為合作夥伴建立其他群組,將這項存取權控管模式擴展至雲端資源。這可能會導致深層巢狀群組大量增加,變得難以管理。

貴機構也可能設有政策,限制您可建立的群組數量,以維持使用者目錄層級的合理平坦度。為避免 IAM 政策設定錯誤,並限制群組成長,建議使用多個集區,進一步區隔不同機構單位、業務單位和合作夥伴機構的使用者。然後,您可以參照這些集區和集區內含的群組,定義 IAM 政策 (請參閱「設定 IAM」步驟中的範例)。

VPC Service Controls 限制

員工身分聯盟管理功能 (包括員工集區設定 API 和 Security Token Service API) 不支援 VPC Service Controls。不過, Google Cloud 同時支援員工身分聯盟VPC Service Controls 的產品,會按照文件說明運作,並接受 VPC Service Controls 政策檢查。此外,您可以在 VPC Service Controls 的輸入或輸出規則中使用第三方身分,例如員工集區使用者和工作負載身分。

員工身分聯盟和重要聯絡人

使用員工身分聯盟時,請務必提供重要聯絡人,以便接收貴機構或產品異動的重要資訊。Google Cloud Cloud Identity 使用者可透過 Cloud Identity 電子郵件地址聯絡,但員工身分聯盟使用者則透過重要聯絡人聯絡。

使用 Google Cloud 控制台建立或管理員工身分集區時,系統會顯示橫幅,要求您設定「法律」和「停權」類別的重要聯絡人。如果沒有個別聯絡人,也可以在「所有」類別中定義聯絡人。提供聯絡人資訊後,系統就會移除橫幅。

後續步驟