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

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

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

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

サポートされるクラスタタイプ

GKE クラスタで Connect Gateway を使用している場合は、GKE Identity Service の設定をすべて完了して認可に Google グループを使用する必要はありません。代わりに、RBAC 用の Google グループを構成するの手順に沿って設定します。これにより、ユーザーはアクセス制御に Google グループを使用して Google Cloud コンソールから GKE クラスタにログインすることもできます。これを行うと、後述の Google グループに IAM のロールを付与するの手順に沿って、グループのメンバーが Connect Gateway を介してクラスタにアクセスできるようになります。

GKE Enterprise 1.13 以降では登録済みの GKE クラスタ、GKE on VMwareGoogle Distributed Cloud Virtual for Bare Metal に、Kubernetes バージョン 1.25 以降では GKE on AWSGKE on Azure に対して、Connect Gateway を介した Google グループによるアクセス制御を設定できます。この機能を使用するためにオンプレミス クラスタをアップグレードする必要がある場合は、VMWare 用 GKE Enterprise クラスタのアップグレードベアメタル用 GKE Enterprise クラスタのアップグレードをご覧ください。

この機能を上記以外の接続クラスタまたは GKE クラスタ環境で使用する場合は、Cloud カスタマーケアまたは Connect Gateway チームにお問い合わせください。

仕組み

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

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

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

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

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

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

始める前に

  • 次のコマンドライン ツールがインストールされていることを確認します。

    • Google Cloud CLI の最新バージョン。Google Cloud の操作に使用するコマンドライン ツールです。
    • Kubernetes コマンドライン ツール kubectl。クラスタとのやり取りに使用します。

    Google Cloud を操作するシェル環境として Cloud Shell を使用する場合は、これらのツールがインストールされます。

  • プロジェクトで使用する gcloud CLI が初期化されていることを確認します。

  • このガイドでは、プロジェクトに roles/owner があることを前提としています。プロジェクト オーナーでない場合は、設定手順を行うために追加の権限が必要になる場合があります。

  • Google Cloud 外のクラスタの場合、GKE Identity Service はクラスタから Google Identity API を呼び出す必要があります。ネットワーク ポリシーでアウトバウンド トラフィックがプロキシを経由する必要があるかどうかを確認します。

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

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

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

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

API を有効にする

Gateway をプロジェクトに追加するには、Connect Gateway API と必要な依存関係 API を有効にします。ユーザーが Google Cloud コンソールを使用してクラスタに対する認証のみを行う場合、connectgateway.googleapis.com を有効にする必要はありませんが、他の API を有効にする必要があります。

PROJECT_ID=example_project
gcloud services enable --project=${PROJECT_ID}  \
connectgateway.googleapis.com \
anthos.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com

GKE Identity Service を設定する

Connect Gateway の Google グループ機能は、GKE Identity Service を使用して Google からグループ メンバーシップ情報を取得します。GKE Identity Service の詳細については、GKE Identity Service の概要をご覧ください。

Gateway で GKE クラスタを使用している場合は、Google グループのアクセス制御を使用するように GKE Identity Service を設定する必要はありません。代わりに、RBAC 用の Google グループを構成するの手順に沿って設定し、Google グループに IAM のロールを付与するの説明に従って、グループ メンバーが Connect Gateway を介してクラスタにアクセスできるようにします。

GKE Identity Service がインストールされていることを確認する

GKE Identity Service は、バージョン 1.7 以降の GKE クラスタにデフォルトでインストールされています(Google グループの機能にはバージョン 1.13 以降が必要です)。次のコマンドを実行すると、クラスタに正しくインストールされていることを確認できます。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get all -n anthos-identity-service

ここで

USER_CLUSTER_KUBECONFIG は、クラスタの kubeconfig ファイルのパスです。

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

GKE on AWS または GKE on Azure を使用している場合、クラスタは自動的に Google グループをサポートするように構成されます。Google グループに IAM ロールを付与するに進んでください。

GKE on Bare Metal または GKE on VMware を使用している場合、GKE Identity Service の設定方法に応じて、Google グループ機能の構成方法が決まります。

GKE Identity Service を初めて使用する場合は、Google グループをフリートレベル(推奨)またはクラスタごとのいずれで構成するかを選択できます。

GKE Identity Service の使用が初めてでない場合は、次の点に留意してください。

  • 別の ID プロバイダ用にすでにフリートレベルで GKE Identity Service を設定している場合、Google グループ機能はデフォルトで有効になっています。詳細と必要な追加設定については、以下の「フリート」をご覧ください。
  • 別の ID プロバイダ用にすでにクラスタごとに GKE Identity Service を設定している場合は、以下の「クラスタごと」で、Google グループ機能の構成を更新する手順を確認してください。

フリート

Google Cloud コンソールまたはコマンドラインを使用して、フリート単位で Google グループへのアクセスを構成できます。

別の ID プロバイダ(Microsoft AD FS や Okta など)でフリートレベルで GKE Identity Service をすでに構成している場合、Google ID プロバイダがプロキシなしで到達可能であれば、構成したクラスタ上で Connect Gateway の Google グループ機能がデフォルトで有効になります。

コンソール

フリートに GKE Identity Service をまだ設定していない場合は、GKE Identity Service のクラスタを構成するの説明に従って設定します。

クラスタを選択して構成を更新する

  1. Google Cloud コンソールで、GKE Enterprise の [機能] ページに移動します。

    GKE Enterprise の [機能] に移動

  2. [機能] テーブルの [Identity Service] 行の [詳細] をクリックします。プロジェクトのクラスタの詳細が表示されます。

  3. [Identity Service の更新] をクリックして、設定ペインを開きます。

  4. 構成するクラスタを選択します。個々のクラスタを選択するか、すべてのクラスタを同じ ID 構成にするように指定できます。

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

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

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

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

gcloud

フリートに GKE Identity Service をまだ設定していない場合は、GKE Identity Service のクラスタを構成するの説明に従って設定します。auth-config.yaml ファイルでは次の構成のみを指定します。

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

プロキシを使用した Google グループのアクセス権の構成

プロキシ経由で ID プロバイダにアクセスする必要がある場合は、auth-config.yaml ファイルの proxy フィールドを使用します。たとえば、クラスタがプライベート ネットワークにあり、パブリック ID プロバイダに接続する必要がある場合に設定する必要があります。別のプロバイダ用に GKE Identity Service をすでに構成している場合でも、この構成を追加する必要があります。

proxy を構成するために、既存の構成ファイル auth-config.yamlauthentication セクションを更新する方法は次のとおりです。

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

ここで

  • disable(省略可)は、クラスタの Google グループ機能を有効にするかどうかを指定します。このオプションはデフォルトで false に設定されています。この機能を無効にする場合は、true に設定します。

  • 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 は、フリート内のクラスタの一意のメンバーシップ名です。

一度適用されると、この構成は GKE Identity Service コントローラによって管理されます。GKE Identity Service のクライアント構成にローカルで加えられた変更は、コントローラにより、この設定に指定された構成に戻されます。

クラスタごと

Google グループ機能を使用して、GKE Identity Service を使用するようにクラスタを構成するには、クラスタの GKE Identity Service ClientConfig を更新する必要があります。これは、クラスタ構成に使用される Kubernetes カスタム リソースタイプ(CRD)です。各 GKE Enterprise クラスタには、構成の詳細で更新する kube-public Namespace に default という名前の ClientConfig リソースがあります。

構成を編集するには、次のコマンドを使用します。

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

ここで、USER_CLUSTER_KUBECONFIG はクラスタの kubeconfig ファイルのパスです。

kubeconfig に複数のコンテキストがある場合は、現行のコンテキストが使用されます。コマンドを実行する前に、現在のコンテキストを正しいクラスタにリセットすることが必要になる場合があります。

次の例では、タイプ google の構成を持つ新しい認証方法を使用して ClientConfig を更新し、Google グループ機能を有効にする方法を示します。internalServer フィールドが空の場合は、次のように https://kubernetes.default.svc に設定されていることを確認します。

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

ここで

CLUSTER_IDENTIFIER(必須)はクラスタのメンバーシップの詳細を示します。次のコマンドを使用して、クラスタのメンバーシップの詳細を取得できます。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yaml

ここで

USER_CLUSTER_KUBECONFIG は、クラスタの kubeconfig ファイルのパスです。レスポンスの spec.owner.id フィールドを参照して、クラスタのメンバーシップの詳細を取得します。

以下に、クラスタのメンバーシップの詳細を示すレスポンスの例を示します。

id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef

これは、//gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP という形式に対応します。

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.gatewayAdminroles/gkehub.gatewayReadergkehub.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 認証の使用をご覧ください。

次のステップ

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