使用 OpenID Connect (OIDC) 進行驗證

瞭解如何設定 AWS 上的 GKE，使用 OpenID Connect (OIDC) 驗證使用者叢集。本主題說明如何使用任何 OpenID 提供者設定 GKE on AWS。

如要將使用 OIDC 驗證的叢集升級至 Kubernetes 1.21，請參閱「升級至 1.21」。

如要瞭解 GKE on AWS 驗證流程，請參閱「驗證」。

總覽

GKE on AWS 支援 OIDC，可做為與使用者叢集 Kubernetes API 伺服器互動的驗證機制。透過 OIDC，您可以使用貴機構建立、啟用及停用使用者帳戶的標準程序，管理 Kubernetes 叢集的存取權。

事前準備

• 本主題假設您熟悉下列驗證和 OpenID 概念：

  • OAuth 2.0
  • OpenID Connect
  • 範圍
  • 聲明

• 每位開發人員的本機都必須安裝 Google Cloud CLI。

• 不支援無螢幕系統。如要進行驗證，您必須在本機開啟瀏覽器，並執行 gcloud CLI。瀏覽器隨即會提示您授權使用者帳戶。

• 如要透過 Google Cloud 控制台進行驗證，您必須向 Google Cloud註冊要設定 OIDC 驗證的每個叢集。

職位

本主題將介紹三種角色：

• 機構管理員：選擇 OpenID 提供者，並向該提供者註冊用戶端應用程式。

• 叢集管理員：建立一或多個使用者叢集，並為使用叢集的開發人員建立驗證設定檔。

• 開發人員：在一個或多個叢集上執行工作負載，並使用 OIDC 進行驗證。

選擇 OpenID 提供者

本節內容適用於機構管理員。

您可以選擇使用任何 OpenID 供應商。如需通過認證的供應商清單，請參閱「OpenID 認證」。

建立重新導向網址

本節內容適用於機構管理員。

OpenID 提供者會使用重新導向網址傳回 ID 權杖。您必須為 gcloud CLI 和Google Cloud 控制台建立重新導向網址。

設定 gcloud CLI 重新導向網址

設定 OpenID 提供者時，請將 CLI 重新導向網址指定為 http://localhost:PORT/callback

將 PORT 替換為大於 1024 的通訊埠號碼。

設定 Google Cloud 主控台重新導向網址

Google Cloud 控制台的重新導向網址為：

https://console.cloud.google.com/kubernetes/oidc

設定 OIDC 供應商時，請將 https://console.cloud.google.com/kubernetes/oidc 指定為其中一個重新導向網址。

向 OpenID 提供者註冊用戶端應用程式

本節內容適用於機構管理員。

開發人員必須先向 OpenID 提供者註冊這兩個用戶端，才能透過 Google Cloud CLI 或 Google Cloud 控制台 使用 OpenID 提供者。註冊步驟如下：

• 瞭解供應商的核發者 URI。gcloud CLI 或Google Cloud 控制台會將驗證要求傳送至這個 URI。

• 使用重新導向網址 (包括通訊埠號碼) 設定供應商，以供 gcloud CLI 使用。

• 使用 Google Cloud 控制台的重新導向網址設定供應商， https://console.cloud.google.com/kubernetes/oidc。

• 建立單一用戶端 ID，供供應商用來識別 Google Cloud CLI 和Google Cloud 控制台。

• 建立單一用戶端密鑰，供 gcloud CLI 和 Google Cloud 控制台用來向 OpenID 提供者進行驗證。

• 建立自訂範圍，供 gcloud CLI 或 Google Cloud 控制台 用來要求使用者的安全性群組。

• 建立自訂憑證附加資訊名稱，供應商會使用這個名稱傳回使用者的安全性群組。

設定叢集

本節適用於叢集管理員。

如要設定 OIDC 驗證，您需要使用叢集的驗證詳細資料，設定使用者叢集的 AWSCluster 資源。AWSCluster 的詳細資料會用於設定 Google Cloud 控制台和 GKE Enterprise 的 Authentication Plugin 的 OIDC。設定包含下列 OIDC 資訊：

authentication:
  awsIAM:
    adminIdentityARNs:
      - AWS_IAM_ARN
  oidc:
  -   certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET 
      extraParams:  EXTRA_PARAMS
      groupsClaim:  GROUPS_CLAIM
      groupPrefix:  GROUP_PREFIX
      issuerURI:  ISSUER_URI
      kubectlRedirectURI:  KUBECTL_REDIRECT_URI
      scopes:  SCOPES
      userClaim:  USER_CLAIM
      userPrefix:  USER_PREFIX

驗證欄位

下表說明 authentication.awsIAM.adminIdentityARNs 物件的欄位。

範例：授權使用者和群組

許多供應商會在權杖中編碼使用者識別屬性，例如電子郵件和使用者 ID。不過，這些屬性會對驗證政策造成隱含風險：

• 使用者 ID 會讓政策難以閱讀和稽核。
• 使用電子郵件地址可能會造成可用性風險 (如果使用者變更主要電子郵件地址)，以及安全性風險 (如果電子郵件地址可以重新指派)。

建議您使用群組政策，而非指派使用者 ID，因為群組政策不僅可持續存在，也更容易稽核。

假設供應商建立的 ID 權杖包含下列欄位：

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

根據這個權杖格式，您會填入設定檔的 oidc 規格，如下所示：

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

建立使用者叢集後，您可以使用 Kubernetes 角色型存取權控管 (RBAC) 機制，將特殊存取權授予已通過驗證的使用者。

在下列範例中，您會建立 ClusterRole，授予使用者叢集密鑰的唯讀存取權，並建立 ClusterRoleBinding 資源，將角色繫結至已驗證的群組。

1. 定義 ClusterRole。將下列 YAML 複製到名為 secret-reader-role.yaml 的檔案。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-reader
   rules:
   - apiGroups: [""]
     # The resource type for which access is granted
     resources: ["secrets"]
     # The permissions granted by the ClusterRole
     verbs: ["get", "watch", "list"]
   

2. 定義 ClusterRoleBinding。將下列 YAML 複製到名為 secret-reader-admins.yaml 的檔案。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: read-secrets-admins
   subjects:
     # Allows anyone in the "us-east1-cluster-admins" group to
     # read Secrets in any namespace within this cluster.
   - kind: Group
     name: gid-us-east1-cluster-admins # Name is case sensitive
     apiGroup: rbac.authorization.k8s.io
     # Allows this specific user to read Secrets in any
     # namespace within this cluster
   - kind: User
     name: uid-u98523-4509823
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-reader
     apiGroup: rbac.authorization.k8s.io
   

3. 使用 kubectl 將 secret-reader-role.yaml 和 secret-reader-admins.yaml 套用至叢集。

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl apply -f secret-reader-role.yaml && \
     kubectl apply -f secret-reader-admins.yaml
   

   在 read-secrets-admins 中獲得存取權的使用者，現在可以讀取叢集中的密鑰。

建立登入設定

本節適用於叢集管理員。

建立使用者叢集後，您需要使用 gcloud anthos create-login-config 為叢集產生設定檔。

1. 在 anthos-aws 目錄中，使用 anthos-gke 將環境切換至使用者叢集。

   cd anthos-aws
   env HTTPS_PROXY=http://localhost:8118 \
     anthos-gke aws clusters get-credentials CLUSTER_NAME

   將 CLUSTER_NAME 替換為使用者叢集名稱。

2. 使用 gcloud anthos 建立設定。

   gcloud anthos create-login-config --kubeconfig usercluster-kubeconfig
   

   將 usercluster-kubeconfig 替換為使用者叢集的 kubeconfig 檔案路徑。在 Linux 和 macOS 上，這個檔案預設位於 ~/.kube/config。

這個指令會產生檔案 (kubectl-anthos-config.yaml)，其中包含開發人員用來透過 gcloud CLI 向叢集驗證身分的設定資訊。請勿修改這個檔案。

如要進一步瞭解 kubectl-anthos-config.yaml 的內容，請參閱附錄。

發布登入設定

將設定檔發送給需要向使用者叢集驗證身分的使用者。您可以透過下列方式發布設定：

• 將檔案放在預設目錄中。
• 安全地發布檔案。
• 將檔案託管在 HTTPS 伺服器上。

登入設定預設目錄

各作業系統的設定檔預設儲存位置如下：

Linux

$HOME/.config/google/anthos/kubectl-anthos-config.yaml，其中 $HOME 是使用者的主目錄。

macOS

$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml，其中 $HOME 是使用者的主目錄。

Windows

%APPDATA%/google/anthos/kubectl-anthos-config.yaml，其中 %APPDATA% 是使用者的應用程式資料目錄。

登入設定發布後，開發人員即可設定 gcloud CLI 來存取叢集。

升級至 Kubernetes 1.21 後修改叢集

將叢集升級至 Kubernetes 1.21 後，您必須設定 GKE Identity Service，並從叢集的設定中移除 OIDC 資訊。如要更新設定，請按照下列步驟操作：

1. 按照「升級叢集」中的步驟操作。

2. 在 anthos-aws 目錄中，使用 anthos-gke 將環境切換至使用者叢集。

   cd anthos-aws
   env HTTPS_PROXY=http://localhost:8118 \
     anthos-gke aws clusters get-credentials CLUSTER_NAME

   將 CLUSTER_NAME 替換為使用者叢集名稱。

3. 在文字編輯器中開啟包含 AWSCluster 的資訊清單。 保持檔案開啟，並使用 oidc 物件的值，按照「為 GKE Identity Service 設定叢集」中的步驟操作。

4. 從 anthos-aws 目錄使用 anthos-gke 將環境切換至管理服務。

   cd anthos-aws
   anthos-gke aws management get-credentials

5. 在文字編輯器中開啟建立 AWSCluster 的 YAML 檔案。如果沒有初始 YAML 檔案，可以使用 kubectl edit。

   編輯 YAML

   如果您按照「建立使用者叢集」一文中的操作說明進行，YAML 檔案會命名為 cluster-0.yaml。在文字編輯器中開啟這個檔案。

   kubectl edit

   如要使用 kubectl edit 編輯 AWSCluster，請執行下列指令：

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl edit awscluster cluster-name
   

   將 cluster-name 替換為您的 AWSCluster。舉例來說，如要編輯預設叢集 cluster-0，請執行下列指令：

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl edit awscluster cluster-0
   

6. 從叢集資訊清單中刪除 oidc 物件。

7. 儲存檔案。如果您使用 kubectl edit，kubectl 會自動套用變更。如果您要編輯 YAML 檔案，請使用下列指令將檔案套用至管理服務：

   env HTTPS_PROXY=http://localhost:8118 \
     kubectl apply -f cluster-0.yaml
   

   管理服務隨後會更新 AWSCluster。

設定 gcloud 以存取叢集

本節適用於開發人員或叢集管理員。

必要條件

如要完成這個部分，請完成下列事項：

• 登入設定。

• 更新後的 gcloud CLI 版本，其中包含 anthos-auth 元件。

  gcloud components update
  gcloud components install anthos-auth
  

• 執行下列指令，確認 gcloud CLI 是否已成功安裝。如果安裝成功，指令應會傳回必要引數和可用選項的詳細資料。

  gcloud anthos auth
  

驗證叢集

您可以透過下列方式驗證叢集：

• 在本機電腦上使用 gcloud CLI。
• 透過安全殼層通道，在遠端電腦上使用 gcloud CLI。

• 使用 Google Cloud 主機上的「連線」。

gcloud anthos auth login --cluster CLUSTER_NAME

gcloud anthos auth login --cluster CLUSTER_NAME \
--user USERNAME --login-config ANTHOS_CONFIG_YAML \
--login-config-cert LOGIN_CONFIG_CERT_PEM \
--kubeconfig=KUBECONFIG --dry-run

env HTTPS_PROXY=http://localhost:8118 \
  kubectl get nodes --kubeconfig my.kubeconfig

ssh USERNAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

更新 OIDC 設定

如要更新叢集上的 OIDC 設定，請使用 kubectl edit 指令。

env HTTPS_PROXY=http://localhost:8118 \
  kubectl edit clientconfigs -n kube-public default

kubectl 工具會在預設編輯器中載入 ClientConfig 資源。如要更新設定，請儲存檔案。kubectl 工具會更新叢集上的 ClientConfig 資源。

如要瞭解 ClientConfig 資源的內容，請參閱下一節。

附錄：登入設定範例

範例如下 kubectl-anthos-config.yaml。這個範例僅供瞭解內容。建議您一律使用 gcloud anthos create-login-config 產生檔案。

apiVersion: authentication.gke.io/v2alpha1
kind: ClientConfig
metadata:
 name: default
 namespace: kube-public
spec:
  authentication:
  - name: oidc
    oidc:
      clientID: CLIENT_CONFIG
      clientSecret: CLIENT_SECRET
      extraParams: resource=k8s-group-claim,domain_hint=consumers
      certificateAuthorityData:   CERTIFICATE_STRING
      issuerURI: https://adfs.contoso.com/adfs
      kubectlRedirectURI: http://redirect.kubectl.com/
      scopes: allatclaim,group
      userClaim: "sub"
      groupsClaim: "groups"
    proxy: PROXY_URL #Optional
  certificateAuthorityData: CERTIFICATE_AUTHORITY_DATA
  name: projects/my-project/locations/global/membership/cluster-0
  server: https://192.168.0.1:PORT
  preferredAuthentication: oidc

如要瞭解欄位內容，請參閱「驗證欄位」。

後續步驟

部署第一個工作負載至 GKE on AWS。