Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

サードパーティの ID を使用して Connect Gateway を設定する

このガイドは、Google ID がなく Google Workspace に属していないユーザーが含まれるプロジェクトで、Connect Gateway を設定する必要のあるプラットフォーム管理者を対象としています。このガイドでは、これらの ID を「サードパーティの ID」と呼びます。このガイドを読む前に、 Connect Gateway の概要のコンセプトを理解しておく必要があります。個々の Google アカウントを承認するには、 Connect Gateway の設定をご覧ください。 Google グループのサポートについては、 Google グループでの Connect Gateway の設定をご覧ください。

このガイドの設定では、ユーザーは Google Cloud CLI、Connect Gateway、コンソールを使用してフリートクラスタにログインできます。 Google Cloud

サポートされるクラスタの種類

次のクラスタタイプに対して、Connect Gateway を介したサードパーティの ID によるアクセス制御を設定できます。

上の GKE Google Cloud: 利用可能なすべてのバージョン。Connect Gateway を設定するには、 RBAC 用の Google グループを構成し、 Google グループに IAM のロールを付与します。
VMware とベアメタル上の Google Distributed Cloud（ソフトウェアのみ）: 利用可能なすべてのバージョン。
Google Distributed Cloud コネクテッド: 利用可能なすべてのバージョン。
GKE 接続クラスタ: バージョン 1.28.0-gke.2 以降。
GKE on AWS と GKE on Azure: 利用可能なすべてのバージョン。

注意: GKE on AWS と GKE on Azure は非推奨となっています。詳細については、 GKE on AWS のサポート終了のお知らせと GKE on Azure のサポート終了のお知らせをご覧ください。

上記リストにない環境でこの機能を使用するには、 Cloud カスタマーケアまたは Connect Gateway チームにお問い合わせください。

仕組み

概要で説明されているように、ユーザーは Google Workspace と Cloud Identity 以外の ID プロバイダを使用している可能性があります。Workforce Identity 連携を使用すると、ユーザーは Okta や Azure Active Directory などのサードパーティ ID プロバイダを使用して Connect Gateway 経由でクラスタにアクセスできます。Google アカウントとは異なり、サードパーティのユーザーは Identity and Access Management（IAM）の次の形式で表されます。

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE

WORKFORCE_POOL_ID は、関連するサードパーティの ID プロバイダを含む Workforce プールの名前です。
SUBJECT_VALUE は、サードパーティの ID の Google サブジェクトへのマッピングです。

サードパーティグループの場合、IAM プリンシパルは次の形式になります。

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_VALUE

次の図は、サードパーティのユーザーがこのサービスを有効にしてクラスタの認証を行い、コマンドを実行する一般的なフローを示しています。このフローを成功させるには、ユーザーまたはグループのいずれかのロールベースアクセス制御（RBAC）ポリシーをクラスタに適用する必要があります。

個々のユーザーの場合、ユーザーの完全な IAM プリンシパル名を使用する RBAC ポリシーがクラスタに存在する必要があります。

グループ機能を使用する場合、完全な IAM プリンシパル名を使用する RBAC ポリシーが、次のグループのクラスタに存在する必要があります。

ユーザー alice@example.com をメンバーに含むグループ。
Alice Google Cloud の組織にある Workforce プール内の ID プロバイダのマッピングに含まれているグループ。

Gateway のサードパーティ ID フローを示す図

ユーザー alice@example.com がサードパーティのブラウザベースのログインを使用して、サードパーティの ID で gcloud CLI にログインします。コマンドラインからクラスタを使用するため、Connect Gateway の使用で説明されているように、ユーザーがクラスタの Gateway kubeconfig を取得します。
ユーザーが kubectl コマンドを実行するか、コンソール Google Cloud で Google Kubernetes Engine の [ワークロード] または [オブジェクトブラウザ] ページを開いてリクエストを送信します。
リクエストが Connect Gateway によって受信されます。Connect Gateway は、Workforce Identity 連携を使用してサードパーティの認証を処理します。
Connect Gateway で IAM による承認チェックが実行されます。
Connect Service は、クラスタで動作している Connect Agent にリクエストを転送します。このリクエストには、クラスタの認証と認可で使用するためのユーザーの認証情報が含まれています。
Connect Agent が、リクエストを Kubernetes API サーバーに転送します。
Kubernetes API サーバーは、リクエストをクラスタ内のアカウント管理サービスコンポーネントに転送し、アカウント管理サービスコンポーネントでリクエストが検証されます。
アカウント管理サービスコンポーネントによって、サードパーティのユーザーとグループの情報が Kubernetes API サーバーに返されます。Kubernetes API サーバーでこの情報を使用して、クラスタの構成済み RBAC ポリシーに基づいてリクエストを承認できます。

始める前に

アカウントに Google Cloud ログインします。 Google Cloudを初めて使用する場合は、アカウントを作成して、実際のシナリオで Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

Google Cloud CLI をインストールします。

注: すでに gcloud CLI をインストールしている場合は、 `gcloud components update` gcloud components updateを実行して、最新バージョンがインストールされていることを確認してください。

外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。

gcloud CLI を初期化するには、次のコマンドを実行します:

gcloud init

このガイドを完了するために必要な権限があることを確認します。

Connect Gateway、GKE Connect、GKE Hub、Anthos Identity Service、Cloud Resource Manager API を有効にします。

API を有効にするために必要なロール

API を有効にするには、serviceusage.services.enable 権限が必要です。プロジェクトを作成した場合は、オーナーロール（roles/owner）を介してこの権限がすでに付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール（roles/serviceusage.serviceUsageAdmin）を介してこの権限を取得できます。ロールを付与する方法をご覧ください。

gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

Google Cloud CLI をインストールします。

外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。

gcloud CLI を初期化するには、次のコマンドを実行します:

gcloud init

このガイドを完了するために必要な権限があることを確認します。

Connect Gateway、GKE Connect、GKE Hub、Anthos Identity Service、Cloud Resource Manager API を有効にします。

API を有効にするために必要なロール

gcloud services enable connectgateway.googleapis.com gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com

Google Cloud以外のクラスタの場合、クラスタ内の認証コンポーネントは Cloud Identity API を呼び出す必要があります。クラスタからの下り（外向き）トラフィックがプロキシを経由する必要があるネットワークポリシーがあるかどうかを確認します。

必要なロール

Connect Gateway とクラスタを構成するために必要な権限を取得するには、プロジェクトに対する編集者（roles/editor）IAM ロールを付与するよう管理者に依頼します。ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

Workforce Identity 連携を使用してサードパーティの ID 属性のマッピングを設定する

ID プロバイダに対応する手順に沿って、 Google Cloud 組織用に Workforce プールと ID プロバイダが設定されていることを確認します。

グループのサポートを構成する

Connect Gateway は、クラスタ内の認証コンポーネントを使用してグループメンバーシップ情報を取得します。必要なコンポーネントを有効にするには、クラスタタイプに応じて次のいずれかのドキュメントをご覧ください。

上の GKE Google Cloud: RBAC 用の Google グループを構成し, グループに IAM のロールを付与するセクションに進みます。
GKE 接続クラスタ:
Google Distributed Cloud: クラスタ内の ClientConfig カスタムリソースを更新して、グループのサポートを有効にします。 Distributed Cloud は、すべてのクラスタの kube-public Namespace に default という名前の ClientConfig を自動的に作成します。このカスタムリソースが存在することを確認するには、次のコマンドを実行します。
```
kubectl --kubeconfig CLUSTER_KUBECONFIG get ClientConfig default -n kube-public
```
CLUSTER_KUBECONFIG は、クラスタの kubeconfig のパスに置き換えます。

クラスタまたはフリートがすでに Google グループのサポート用に構成されている場合は、追加の手順はありません。IAM ロールをサードパーティのユーザーとグループに付与するまでスキップできます。

以降のセクションでは、グループのサポートを有効にするように ClientConfig カスタムリソースを更新する方法について説明します。これらのセクションは、Google Distributed Cloud クラスタにのみ適用されます。GKE on Google Cloud、GKE on AWS、GKE on Azure などの他のタイプのクラスタの場合は、グループに IAM のロールを付与するセクションに進みます。

Distributed Cloud では、個々のクラスタまたはフリートのグループのサポートを構成できます。使用するクラスタのタイプによって、グループのサポートを構成する方法は次のように異なります。

Distributed Cloud コネクテッド: 個々のクラスタのみ。フリートレベルの構成はサポートされていません。
VMware とベアメタル上の Google Distributed Cloud（ソフトウェアのみ）: 個々のクラスタまたはフリート。

GKE Fleet API を使用してグループのサポートを構成する

VMware とベアメタル上の Google Distributed Cloud（ソフトウェアのみ）の場合、フリートレベルでグループのサポートを構成できます。別の ID プロバイダなど、フリートレベルの認証を以前に構成している場合、グループ認証はすでに有効になっています。ただし、ネットワークポリシーで下り（外向き）トラフィックがプロキシを経由する必要がある場合は、そのプロキシに関する情報を使用して既存の構成を更新する必要があります。

フリートレベルでグループのサポートを構成するには、次のいずれかのオプションを選択します。

コンソール

コンソール Google Cloud で、[GKE Identity Service] ページに移動します。

GKE Identity Service に移動
[Identity Service を有効にする] をクリックします。
構成する VMware とベアメタル上の Google Distributed Cloud（ソフトウェアのみ）クラスタを選択します。
[構成の更新] をクリックします。[Identity Service クラスタ構成の編集] ペインが開きます。
[Configure Identity Providers] セクションで、ID プロバイダの保持、追加、更新、削除を選択できます。
[続行] をクリックして、次の構成ステップに進みます。この設定に対して少なくとも 1 つの有効なクラスタを選択した場合は、[Google 認証] セクションが表示されます。
選択したクラスタで Google 認証を有効にするには、[有効にする] を選択します。プロキシ経由で Google ID プロバイダにアクセスする必要がある場合は、[プロキシ] に詳細を入力します。
[構成の更新] をクリックします。これにより、選択したクラスタに ID 構成が適用されます。

gcloud

フリートレベルの Identity Service 機能を有効にしてクラスタを構成します。これは、フリートレベルの認証管理を設定するで説明されています。
ClientConfig 仕様を含む auth-config.yaml ファイルに、次のフィールドを追加します。
```
spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false
```
google.disable フィールドの値が false の場合、グループのサポートが有効になります。グループのサポートを無効にするには、この値を true に変更します。
省略可: プロキシ経由で Google ID プロバイダにアクセスする必要がある場合は、上記の構成に proxy フィールドを追加します。
```
spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false
    proxy: PROXY_URL
```
PROXY_URL は、Google ID に接続するプロキシサーバーのアドレスに置き換えます。例: http://user:password@10.10.10.10:8888
構成をフリート内のクラスタに適用します。
```
gcloud container fleet identity-service apply \
--membership=CLUSTER_NAME \
--config=/path/to/auth-config.yaml
```
CLUSTER_NAME は、フリート内のクラスタの一意のメンバーシップ名に置き換えます。

フリートレベルでグループのサポートを設定すると、フリートコントローラが構成を管理します。フリートレベルの構成は、特定のクラスタの構成に対するローカル変更を上書きします。

個々のクラスタのグループのサポートを構成する

Distributed Cloud コネクテッドを含むすべての Distributed Cloud クラスタで、各クラスタの default ClientConfig を更新してグループのサポートを有効にします。

クラスタのメンバーシップの詳細を取得します。
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml
```
USER_CLUSTER_KUBECONFIG は、クラスタの kubeconfig ファイルのパスに置き換えます。kubeconfig に複数のコンテキストがある場合は、現行のコンテキストが使用されます。コマンドを実行する前に、現在のコンテキストを正しいクラスタにリセットすることが必要になる場合があります。

レスポンスの spec.owner.id フィールドを参照して、クラスタのメンバーシップの詳細を取得します。メンバーシップ ID の形式は //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIPです。

出力は次のようになります。
```
id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef
```

クラスタ内の default ClientConfig を開いて編集します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

グループのサポートを有効にするには、spec.authentication フィールドに google フィールドを追加します。
```
spec:
  internalServer: https://kubernetes.default.svc
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method
```
CLUSTER_IDENTIFIER は、クラスタのメンバーシップの詳細に置き換えます。

internalServer フィールドの値が https://kubernetes.default.svc であることを確認します。
省略可: プロキシ経由で Google ID プロバイダにアクセスする必要がある場合は、上記の構成に proxy フィールドを追加します。
```
spec:
  internalServer: https://kubernetes.default.svc
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method
    proxy: PROXY_URL
```
PROXY_URL は、Google ID に接続するプロキシサーバーのアドレスに置き換えます。例: http://user:password@10.10.10.10:8888

サードパーティのユーザーとグループに IAM のロールを付与する

Gateway 経由で接続されたクラスタを操作するには、グループに次のの追加 Google Cloud ロールが必要です。

roles/gkehub.gatewayAdmin: このロールを付与すると、ユーザーは Connect Gateway API にアクセスできるようになります。
- ユーザーが、接続されたクラスタへの読み取り専用アクセスのみを必要とする場合は、代わりに roles/gkehub.gatewayReader を使用できます。
- ユーザーが接続されたクラスタへの読み取り / 書き込みアクセスを必要とする場合は、代わりに roles/gkehub.gatewayEditor を使用できます。
roles/gkehub.viewer: このロールを使用すると、ユーザーは登録済みクラスタメンバーシップを表示できます。

個々の ID とマッピングされたグループに必要なロールを追加する方法は、次のとおりです。

単一の ID

プロジェクト PROJECT_ID の単一の ID に必要なロールを付与するには、次のコマンドを実行します。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

ここで

PROJECT_ID はプロジェクト ID です。
GATEWAY_ROLE は、roles/gkehub.gatewayAdmin、roles/gkehub.gatewayReader、gkehub.gatewayEditor のいずれかにします。
WORKFORCE_POOL_ID は、Workforce Identity プール ID です。
SUBJECT_VALUE は、ユーザー ID です。

グループ

プロジェクト PROJECT_ID の特定のグループ内のすべての ID に必要なロールを付与するには、次のコマンドを実行します。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

ここで

PROJECT_ID はプロジェクト ID です。
GATEWAY_ROLE は、roles/gkehub.gatewayAdmin、roles/gkehub.gatewayReader、gkehub.gatewayEditor のいずれかにします。
WORKFORCE_POOL_ID は、Workforce プール ID です。
GROUP_ID は、マッピングされた google.groups クレーム内のグループです。

RBAC ポリシーを適用する際に部門属性を指定するなど、その他のカスタマイズについては、Workforce Identity を使用してサードパーティマッピングを設定するに記載されている ID プロバイダの設定をご覧ください。

IAM の権限とロールの付与については、リソースへのアクセス権の付与、変更、取り消しをご覧ください。

ロールベースのアクセス制御（RBAC）ポリシーの構成

最後に、各クラスタの Kubernetes API サーバーは、指定したサードパーティのユーザーとグループから Gateway を経由する kubectl コマンドを許可する必要があります。各クラスタに対して、クラスタ上でサブジェクトが持つ権限を指定する RBAC 権限ポリシーを追加する必要があります。

RBAC ポリシーの対象者は IAM バインディングと同じ形式を使用する必要があります。サードパーティのユーザーは principal://iam.googleapis.com/ で始まり、サードパーティのグループは principalSet://iam.googleapis.com/ で始まります。クラスタに外部のサードパーティの ID からの認証が構成されていない場合は、サードパーティのユーザーロール/クラスタロールに加えて、権限借用ポリシーが必要です。その場合は、これらの RBAC 設定手順に沿って、principal://iam.googleapis.com/ で始まるサードパーティのプリンシパルをユーザーとして追加します。

次の例は、外部のサードパーティの ID からの認証が構成されているクラスタで、サードパーティのグループ cluster-admin のメンバーに権限を付与する方法を示しています。ポリシーファイルを /tmp/admin-permission.yaml として保存し、現在のコンテキストに関連付けられているクラスタに適用できます。

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: "principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply permission policy to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/admin-permission.yaml

RBAC 権限の指定についての詳細は、RBAC 認証の使用をご覧ください。

次のステップ

Connect Gateway を使用して、コマンドラインからクラスタに接続する方法を学習します。
Cloud Build との統合のチュートリアルで、DevOps 自動化の一環として Connect Gateway を使用する方法の例をご覧ください。