Google グループを使用して Connect Gateway を設定する

このガイドは、Google グループを認可に使用して、プロジェクトのユーザーが使用する Connect Gateway を設定する必要のあるプラットフォーム管理者を対象としています。このページを読む前に、 概要でコンセプトを 理解しておいてください。個人アカウントを認可するには、 デフォルトの設定をご覧ください。

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

この機能は、 Google Workspace または Cloud Identity の任意のエディションに関連付けられている Google グループを使用します。

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

次のクラスタタイプに対しては、Connect Gateway 経由での Google グループを使用したアクセス制御を設定できます。

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

仕組み

概要で説明されているように、多くの場合、Google グループ（Google Workspace で作成されたグループ）のメンバーシップに基づいてクラスタへのアクセス権をユーザーに付与できると便利です。グループ メンバーシップに基づいて認証すると、アカウントごとに個別の認証を設定する必要がないため、ポリシーの管理が簡素化され、監査が容易になります。たとえば、クラスタへのアクセスをチームで共有することで、ユーザーがチームに入ったり、チームから抜けたときに、個々のユーザーを手動でクラスタに追加または削除する必要がなくなります。クラスタにログインするユーザーごとに Google グループ メンバーシップ情報を取得するように Connect Gateway を構成できます。これにより、この情報をアクセス制御ポリシーで使用できます。

次に、ユーザーがこのサービスを有効にして、クラスタの認証を行い、コマンドを実行する一般的なフローを示します。このフローが成功するには、次の要件を満たすグループのクラスタに RBAC ポリシーが存在する必要があります。

  1. ユーザー alice@example.com をメンバーに含むグループ。

  2. gke-security-groups@example.com のネストされたグループ。

ゲートウェイの Google グループのフローを示す図

  1. ユーザー alice@example.com が Google ID を使用してログインし、 コマンドラインからクラスタを使用する場合は、クラスタの ゲートウェイ kubeconfig を Connect Gateway の使用で説明されているように取得します。
  2. ユーザーが kubectl コマンドを実行するか、 コンソールで Google Kubernetes Engine の [ワークロード] または [オブジェクト ブラウザ] ページを開いてリクエストを送信します。Google Cloud
  3. リクエストが Connect Service によって受信され、 承認チェックが IAM を使用して実行されます。
  4. Connect Service が、クラスタで動作している Connect Agent にリクエストを転送します。このリクエストには、クラスタの認証と認可で使用するためのユーザーの認証情報が含まれています。
  5. Connect Agent が、リクエストを Kubernetes API サーバーに転送します。
  6. Kubernetes API サーバーでリクエストをクラスタ内の anthos-identity-service Pod に転送すると、anthos-identity-service Pod でリクエストが検証されます。
  7. anthos-identity-service Pod によって、ユーザーとグループの情報が Kubernetes API サーバーに返されます。Kubernetes API サーバーでこの情報を使用して、クラスタの構成済み RBAC ポリシーに基づいてリクエストを承認できます。

始める前に

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

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

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

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

    gcloud init

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

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

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

    API を有効にするには、 権限を含む Service Usage 管理者 IAM ロール（roles/serviceusage.serviceUsageAdmin）が必要です。serviceusage.services.enable詳しくは、ロールを付与する方法をご覧ください。

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

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

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

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

    gcloud init

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

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

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

    API を有効にするには、 権限を含む Service Usage 管理者 IAM ロール（roles/serviceusage.serviceUsageAdmin）が必要です。serviceusage.services.enable詳しくは、ロールを付与する方法をご覧ください。

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

必要なロール

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

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

ユーザーとグループを設定する

この機能で使用するグループが次のように設定されていることを確認します。

  1. 組織の Google Workspace に gke-security-groups@YOUR-DOMAIN という形式のグループがあることを確認します。そのようなグループがない場合は、 組織内でグループを作成するの手順に沿って、Google 管理コンソールでグループを作成します。
  2. グループを別のグループに追加するの手順に沿って、アクセス制御に使用するグループを gke-security-groups のネストされたグループとして追加します。個々のユーザーを gke-security-groups のメンバーとして追加しないでください。

この機能で使用するユーザー アカウントは、グループと同じドメイン名を使用する必要があります。

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

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

次のセクションでは、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 プロバイダなど、フリートレベルの認証を以前に構成している場合、グループ認証はすでに有効になっています。 ただし、ネットワーク ポリシーで下り（外向き）トラフィックがプロキシを経由する必要がある場合は、そのプロキシに関する情報を使用して既存の構成を更新する必要があります。

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

コンソール

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

    GKE Identity Service に移動

  2. [Identity Service を有効にする] をクリックします。

  3. 構成する VMware とベアメタル上の Google Distributed Cloud（ソフトウェアのみ）クラスタを選択します。

  4. [構成の更新] をクリックします。[Identity Service クラスタ構成の編集] ペインが開きます。

  5. [Configure Identity Providers] セクションで、ID プロバイダの保持、追加、更新、削除を選択できます。

  6. [続行] をクリックして、次の構成ステップに進みます。この設定に対して少なくとも 1 つの有効なクラスタを選択した場合は、[Google 認証] セクションが表示されます。

  7. 選択したクラスタで Google 認証を有効にするには、[有効にする] を選択します。プロキシ経由で Google ID プロバイダにアクセスする必要がある場合は、[プロキシ] に詳細を入力します。

  8. [構成の更新] をクリックします。これにより、選択したクラスタに ID 構成が適用されます。

gcloud

  1. フリートレベルの認証管理を設定するの説明に従って、フリートレベルのアカウント管理サービス機能を有効にしてクラスタを構成します。

  2. ClientConfig 仕様を含む auth-config.yaml ファイルに、次のフィールドを追加します。

    spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false

    google.disable フィールドの値が false の場合、グループのサポートが有効になります。グループのサポートを無効にするには、この値を true に変更します。

  3. 省略可: プロキシ経由で 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

  4. 構成をフリート内のクラスタに適用します。

    gcloud container fleet identity-service apply \
--membership=CLUSTER_NAME \
--config=/path/to/auth-config.yaml

    CLUSTER_NAME は、フリート内のクラスタの一意のメンバーシップ名に置き換えます。

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

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

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

  1. クラスタのメンバーシップの詳細を取得します。

    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

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

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

  3. グループのサポートを有効にするには、google フィールドを spec.authentication フィールドに追加します。

    spec:
  internalServer: https://kubernetes.default.svc
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method

    CLUSTER_IDENTIFIER は、クラスタのメンバーシップの詳細に置き換えます。

    internalServer フィールドの値が https://kubernetes.default.svc であることを確認します。

  4. 省略可: プロキシ経由で 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

Google グループに IAM ロールを付与する

Gateway を介して接続クラスタを操作する場合は、グループに次の追加 Google Cloud ロールが必要です。

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

これらのロールは、次のように gcloud projects add-iam-policy-binding コマンドを使用して付与します。

gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=GATEWAY_ROLE PROJECT_ID
gcloud projects add-iam-policy-binding --member=group:GROUP_NAME@DOMAIN --role=roles/gkehub.viewer PROJECT_ID

ここで

  • GROUP_NAME は、ロールを付与する Google グループです。
  • DOMAIN は Google Workspace のドメインです
  • GROUP_NAME@DOMAIN は、gke-security-groups@DOMAIN にネストされたグループです。
  • GATEWAY_ROLE は、roles/gkehub.gatewayAdmin、roles/gkehub.gatewayReader、gkehub.gatewayEditor のいずれかにします。
  • PROJECT_ID はプロジェクトです

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

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

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

次の例では、cluster-admin-team グループのメンバーにクラスタに対する cluster-admin 権限を付与して、ポリシー ファイルを /tmp/admin-permission.yaml として保存し、現在のコンテキストに関連するクラスタに適用する方法を示します。また、gke-security-groups グループの下に cluster-admin-team グループも含めてください。

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: cluster-admin-team@example.com
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 認証の使用をご覧ください。

次のステップ