外部 ID プロバイダを使用して GKE に対する認証を行う

このページでは、外部 ID プロバイダ（IdP）から Google Kubernetes Engine（GKE）クラスタへの認証を構成する方法について説明します。

このページは、OpenID Connect（OIDC）または Security Assertion Markup Language（SAML）2.0 をサポートする外部 IdP を使用するプラットフォーム管理者、オペレーター、ID 管理者、アカウント管理者を対象としています。

このドキュメントをお読みになる前に、次の認証と OpenID のコンセプトを理解しておいてください。

• OAuth 2.0
• SAML 2.0
• OpenID Connect
• OIDC スコープとクレーム
• Kubernetes ロールベース アクセス制御

GKE の外部 IdP 認証方法

推奨 - Workforce Identity 連携

Workforce Identity 連携は、OIDC または SAML 2.0 をサポートする任意の外部 IdP から Cloud de Confiance への認証を可能にする IAM 機能です。Workforce Identity 連携では、クラスタ内インストールは不要で、Autopilot クラスタと Standard クラスタで動作し、 Cloud de Confianceに組み込まれています。詳細については、Workforce Identity 連携に関する IAM ドキュメントをご覧ください。

非推奨 - Identity Service for GKE

GKE Standard クラスタでのみ、GKE は Identity Service for GKE もサポートしています。GKE 用 Identity Service は OIDC IdP 向けに限定されていて、クラスタに追加のコンポーネントをインストールします。GKE では、GKE 用 Identity Service ではなく Workforce Identity 連携を使用することを強くおすすめします。また、GKE 用 Identity Service では、既知の制限事項があることにより、自動スケーリングが機能しません。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。

考慮事項

ヘッドレス システムは、Workforce Identity 連携と Identity Service for GKE の両方でサポートされていません。ブラウザベースの認証フローで、同意を求められ、ユーザー アカウントを承認します。

GKE で Workforce Identity 連携を使用する

GKE クラスタで Workforce Identity 連携を使用するには、次の操作を行います。

1. 組織と外部 IdP の Workforce Identity 連携を設定します。手順については、Workforce Identity 連携を構成するをご覧ください。
2. 外部 IdP から Cloud de Confiance by S3NS Workforce Identity 連携コンソールへのアクセスを設定します。詳細については、コンソール（連携）へのユーザー アクセスを設定するをご覧ください。

3. 次のいずれかの承認メカニズムを使用して、ユーザー アクセスを構成します。

   • Kubernetes ロールベース アクセス制御
   • IAM 許可ポリシー

4. 次の手順に沿ってクラスタにアクセスするようユーザーに伝えます。

   1. 連携 ID を使用して gcloud CLI にログインします。
   2. gcloud container clusters get-credentials を実行して、特定のクラスタに対して認証するように kubectl を構成します。

ロールベース アクセス制御を使用してクラスタへのユーザー アクセスを構成する

Cloud de Confiance は、プリンシパル ID を使用して、Workforce Identity プール内のユーザーを識別します。これらのプリンシパル ID は、Kubernetes のロールベース アクセス制御ポリシーまたは IAM ポリシーで参照できます。次の例のように、個人またはユーザーのグループに権限を付与できます。

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/subject/SUBJECT_ATTRIBUTE_VALUE

principal://iam.googleapis.com/locations/global/workforcePools/full-time-employees/subject/amal@example.com

principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_IDENTITY_POOL/group/GROUP_NAME

principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre

Workforce Identity 連携がサポートするプリンシパル ID については、IAM ポリシーで Workforce プールユーザーを表すをご覧ください。

次の例は、full-time-employees Workforce プールにあるエンティティのうち、IdP トークンでグループ sre に属するエンティティに、Secret に対するクラスタ規模の読み取り専用アクセス権を付与する方法を示しています。

1. 次の ClusterRole マニフェストを secret-viewer-cluster-role.yaml として保存します。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: secret-viewer
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   

   この ClusterRole をバインドするプリンシパルは、Secret を表示できます。

2. 次の ClusterRoleBinding マニフェストを secret-viewer-cluster-role-binding.yaml として保存します。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name:  users-view-secrets
   subjects:
   - kind: Group
     name: principalSet://iam.googleapis.com/locations/global/workforcePools/full-time-employees/group/sre
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-viewer
     apiGroup: rbac.authorization.k8s.io
   

   この ClusterRoleBinding によって、グループ sre に属するすべてのユーザーに secret-viewer ClusterRole が付与されます。

3. ClusterRole と ClusterRoleBinding をデプロイします。

   kubectl apply -f secret-viewer-cluster-role.yaml
   kubectl apply -f secret-viewer-cluster-role-binding.yaml
   

クラスタにログインして認証する

1. Google Cloud CLI を使用してログインします。

2. ユーザーは、次の方法でクラスタに対して認証するように kubectl を構成できます。

   gcloud container clusters get-credentials
   

Identity Service for GKE クラスタを Workforce Identity 連携に移行する

既存の GKE クラスタで Identity Service for GKE を使用している場合は、Workforce Identity 連携に移行します。次の表に示すように、これらのメソッドは異なる構文を使用して同じプリンシパルを参照します。

Workforce Identity 連携を使用するようにクラスタを移行するには、次の操作を行います。

1. 組織と外部 IdP の Workforce Identity 連携を設定します。手順については、Workforce Identity 連携を構成するをご覧ください。

2. クラスタ内の RoleBinding と ClusterRoleBinding のマニフェストを更新して、Workforce Identity 連携の ID 構文を使用します。以下のいずれかの方法を選択します。

   • プログラムによる更新: gke-identity-service-migrator ユーティリティをインストールして実行します。手順については、GoogleCloudPlatform/gke-utilities リポジトリの README をご覧ください。

     このユーティリティは、Identity Service for GKE 構文を使用する既存のロールベース アクセス制御バインディングを検索し、対応する Workforce Identity 連携プリンシパル ID を使用する新しいマニフェストを作成します。

   • 手動更新: 認証済みユーザーまたはグループを参照するバインディングごとに、Workforce Identity 連携識別子構文を使用するオブジェクトのマニフェスト ファイルのコピーを個別に作成します。

3. RoleBinding と ClusterRoleBinding の更新されたマニフェストをクラスタに適用します。

4. Workforce Identity 連携を使用して認証するときに、ユーザーが同じリソースにアクセスできることをテストします。

5. クラスタから廃止されたロールベース アクセス制御バインディングを削除します。

6. Identity Service for GKE を無効にする。

Identity Service for GKE を使用する

GKE Standard モードクラスタで Identity Service for GKE を設定して使用するには、クラスタ管理者が次の手順を行います。

1. クラスタで GKE 用 Identity Service を有効にする。
2. GKE 用 Identity Service を構成する。
3. クラスタのロールベース アクセス制御ポリシーを作成する。

クラスタ管理者が GKE 用 Identity Service を構成すると、デベロッパーはクラスタにログインして認証できるようになります。

GKE 用 Identity Service によって作成された Kubernetes オブジェクト

次の表は、クラスタで GKE 用 Identity Service を有効にするときに作成される Kubernetes オブジェクトを示したものです。

クラスタで GKE 用 Identity Service を有効にする

デフォルトでは、Identity and Access Management（IAM）がクラスタ認証の ID プロバイダとして構成されます。サードパーティの ID プロバイダで OIDC を使用する場合は、Google Cloud CLI を使用して新規または既存のクラスタで GKE 用 Identity Service を有効にできます。

新しいクラスタで GKE 用 Identity Service を有効にする

GKE 用 Identity Service が有効になったクラスタを作成するには、次のコマンドを実行します。

gcloud container clusters create CLUSTER_NAME \
    --enable-identity-service

CLUSTER_NAME は、使用する新しいクラスタの名前に置き換えます。

既存のクラスタで GKE 用 Identity Service を有効にする

既存のクラスタで GKE 用 Identity Service を有効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --enable-identity-service

CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

GKE 用 Identity Service を構成する

default ClientConfig をダウンロードして変更することで、GKE 用 Identity Service を構成できます。

1. default ClientConfig をダウンロードします。

   kubectl get clientconfig default -n kube-public -o yaml > client-config.yaml
   

2. 使用したい設定で spec.authentication セクションを更新します。

   apiVersion: authentication.gke.io/v2alpha1
   kind: ClientConfig
   metadata:
     name: default
     namespace: kube-public
   spec:
     name: cluster-name
     server: https://192.168.0.1:6443
     authentication:
     - name: oidc
       oidc:
         clientID: CLIENT_ID
         certificateAuthorityData: OIDC_PROVIDER_CERTIFICATE
         extraParams: EXTRA_PARAMS
         issuerURI:  ISSUER_URI
         cloudConsoleRedirectURI: https://console.cloud.s3nscloud.fr/kubernetes/oidc
         kubectlRedirectURI: KUBECTL_REDIRECT_URL
         scopes: SCOPES
         userClaim: USER
         groupsClaim: GROUPS
         userPrefix: USER_PREFIX
         groupPrefix: GROUP_PREFIX
   

   次のように置き換えます。

   • CLIENT_ID: OIDC プロバイダに認証リクエストを行うクライアント アプリケーションの ID。
   • OIDC_PROVIDER_CERTIFICATE:（省略可）OIDC プロバイダの PEM 証明書。OIDC プロバイダが自己署名証明書を使用する場合、このフィールドが役立つことがあります。GKE 用 Identity Service には、デフォルトで一連の公開ルートが含まれています。
   • EXTRA_PARAMS: OIDC プロバイダに送信する追加の Key-Value パラメータ。
     • グループを承認するには、resource=token-groups-claim を使用します。
     • Microsoft Azure と Okta を認証するには、prompt=consent を使用します。
     • Cloud Identity の場合は、prompt=consent,access_type=offline を使用します。
   • ISSUER_URI: OIDC 承認リクエストを送信する URL（たとえば、https://example.com/adfs）。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。URI には HTTPS を使用する必要があります。Cloud Identity の場合は、https://accounts.google.com を使用します。
   • KUBECTL_REDIRECT_URL: kubectl oidc login が承認に使用するリダイレクト URL。通常は、http://localhost:PORT/callback という形式です。ここで、PORT はデベロッパー ワークステーションで使用可能な 1024 より大きい番号のポートです（例: http://localhost:10000/callback）。この URL は、クライアント アプリケーションの承認済みのリダイレクト URL として OIDC プロバイダに登録する必要があります。Google Identity を OIDC プロバイダとして使用する場合は、リダイレクト URI を設定するで手順をご覧ください。
   • SCOPES: OIDC プロバイダに送信する追加のスコープ。
     • Microsoft Azure と Okta には offline_access スコープが必要です。
     • Cloud Identity の場合は、openid, email を使用して、email クレーム内のメールアドレスを含む ID トークンを取得します。
   • USER: ID トークンのユーザー クレーム。
   • GROUPS: ID トークンのグループ クレーム。
   • USER_PREFIX: 既存の名前と競合しないように、ユーザー クレームの先頭に付加される接頭辞。デフォルトでは、発行元の接頭辞が Kubernetes API サーバーに渡された userID に追加されます（ユーザー クレームが email の場合を除く）。生成されるユーザー ID は ISSUER_URI#USER です。接頭辞を使用することをおすすめしますが、USER_PREFIX を - に設定すると接頭辞を無効にできます。
   • GROUP_PREFIX: 既存の名前と競合しないように、グループ クレームの先頭に付加される接頭辞。たとえば、foobar という名前の 2 つのグループがある場合、接頭辞 gid- を追加します。結果のグループは gid-foobar です。

3. 更新した構成を適用します。

   kubectl apply -f client-config.yaml
   

   この構成を適用すると、GKE 用 Identity Service がクラスタ内で実行され、gke-oidc-envoy ロードバランサの背後でリクエストを処理します。spec.server フィールドの IP アドレスは、ロードバランサの IP アドレスにする必要があります。spec.server フィールドを変更すると、kubectl コマンドが失敗する可能性があります。

4. client-config.yaml 構成ファイルのコピーを作成します。

   cp client-config.yaml login-config.yaml
   

5. spec.authentication.oidc セクションの clientSecret 設定で login-config.yaml 構成ファイルを更新します。

   clientSecret: CLIENT_SECRET
   

   CLIENT_SECRET は、OIDC クライアント アプリケーションと OIDC プロバイダの間での共有シークレットに置き換えます。

6. 更新した login-config.yaml ファイルをデベロッパーに配布します。

厳格なポリシーを持つクラスタで GKE 用 Identity Service を構成する

厳格なネットワーク ポリシーが設定されているクラスタで想定どおりに動作するように GKE 用 Identity Service を構成するには、次の手順を行います。

1. TCP ポート 15000 のファイアウォール ルールを追加して、コントロール プレーンが ClientConfig 検証 Webhook と通信できるようにします。
2. gke-oidc-envoy が内部ロードバランサとして作成されている場合は、VPC に公開します。
3. クラスタ内のトラフィックを拒否するポリシーが存在する場合は、TCP ポート 8443 にファイアウォール ルールを追加して、gke-oidc-envoy Deployment が gke-oidc-service Deployment と通信できるようにします。

Identity Service for GKE コンポーネント バージョン 0.2.20 以降では、TCP ポート 15000 を使用しません。コンポーネントのバージョンが 0.2.20 以降の場合、ポート 15000 のファイアウォール ルールを追加する必要はありません。コンポーネントのバージョンを確認するには、次のコマンドを実行します。

kubectl describe deployment gke-oidc-envoy -n anthos-identity-service \
    | grep "components.gke.io/component-name: gke-oidc" -A1

ロードバランサにカスタム プロパティを追加する

GKE 用 Identity Service を構成すると、静的 IP アドレスなどのカスタム アノテーションとプロパティを gke-oidc-envoy ロードバランサに追加できます。gke-oidc-envoy Service を編集するには、次のコマンドを実行します。

kubectl edit service gke-oidc-envoy -n anthos-identity-service

GKE の TCP / UDP ロード バランシングの構成の詳細については、LoadBalancer Service のパラメータをご覧ください。

クラスタのロールベース アクセス制御ポリシーを作成する

管理者は Kubernetes ロールベース アクセス制御（RBAC）を使用して、認証済みクラスタ ユーザーにアクセスを許可します。クラスタにロールベース アクセス制御を構成するには、各デベロッパーにロールベース アクセス制御ロールを付与する必要があります。特定の Namespace のリソースへのアクセスを許可するには、Role と RoleBinding を作成します。クラスタ全体のリソースへのアクセスを許可するには、ClusterRole と ClusterRoleBinding を作成します。

たとえば、クラスタ全体のすべての Secret オブジェクトを表示する必要があるユーザーを考えてみましょう。次の手順では、必要なロールベース アクセス制御ロールをこのユーザーに付与します。

1. 次の ClusterRole マニフェストを secret-viewer-cluster-role.yaml として保存します。このロールを付与されたユーザーは、クラスタ内の Secret に対して get、watch、list オペレーションを行えます。

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

2. ClusterRole マニフェストを適用します。

   kubectl apply -f secret-viewer-cluster-role.yaml
   

3. 次の ClusterRoleBinding マニフェストを secret-viewer-cluster-role-binding.yaml として保存します。このバインディングでは、クライアント構成ファイルで定義されているユーザー名に secret-viewer ロールを付与します。

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name:  people-who-view-secrets
   subjects:
   - kind: User
     name: ISSUER_URI#USER
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: secret-viewer
     apiGroup: rbac.authorization.k8s.io
   

   次のように置き換えます。

   • ISSUER_URI: クライアント構成ファイルの spec.authentication.oidc.issuerURI にある発行者 URI。
   • USER: クライアント構成ファイルの spec.authentication.oidc.userClaim で構成されたクレーム名の下のトークンのユーザー ID。

4. ClusterRoleBinding マニフェストを適用します。

   kubectl apply -f secret-viewer-cluster-role-binding.yaml
   

クラスタにログインして認証する

管理者から OIDC 構成ファイルを受け取ったデベロッパーは、クラスタに対する認証を行うことができます。

1. 管理者から提供された login-config.yaml ファイルをダウンロードします。

2. 個別の OIDC コンポーネントを提供する Google Cloud CLI SDK をインストールします。これをインストールするには、次のコマンドを実行します。

   gcloud components install kubectl-oidc
   

3. クラスタに対する認証を行います。

   kubectl oidc login --cluster=CLUSTER_NAME --login-config=login-config.yaml
   

   ウェブブラウザが開き、認証プロセスが完了します。

4. 認証されたら、次のような kubectl コマンドを実行できます。

   kubectl get pods
   

GKE 用 Identity Service を無効にする

gcloud CLI を使用して、GKE 用 Identity Service を無効にできます。GKE 用 Identity Service を無効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --no-enable-identity-service

既知の制限事項

GKE 用 Identity Service を使用してクラスタに対して認証する gke-oidc-envoy コンポーネントではレプリカ数が固定されています。つまり、増加したトラフィックに対応できるように自動的にスケーリングされることはありません。リージョン クラスタでは、このコンポーネントが 3 つのレプリカでデプロイされます。

gke-oidc-envoy のデプロイは直接スケーリングできません。Workforce Identity 連携へ移行して、スケーラブルで堅牢なソリューションとすることを強くおすすめします。

次のステップ

• Workforce Identity 連携の詳細を確認する。
• ワークロードのデプロイの詳細を確認する。