Google グループでの Connect ゲートウェイの設定

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

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

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

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

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

GKE Enterprise 1.13 以降では登録済みの GKE クラスタ、GKE on VMware、Google Distributed Cloud Virtual for Bare Metal について、Kubernetes バージョン 1.25 以降では GKE on AWS と GKE on Azure について、Connect ゲートウェイを介して Google グループによるアクセス制御を設定できます。この機能を使用するためにオンプレミスクラスタをアップグレードする必要がある場合は、GKE Enterprise clusters for VMWare のアップグレードに関するページと GKE Enterprise clusters on bare metal のアップグレードに関するページをご覧ください。

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

仕組み

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

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

ユーザー alice@example.com をメンバーとして格納します。
gke-security-groups@example.com のネストされたグループです。

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

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

始める前に

次のコマンドラインツールがインストールされていることを確認します。
- Google Cloud とやり取りするためのコマンドラインツールである、Google Cloud CLI の最新バージョン。
- クラスタを操作するための Kubernetes コマンドラインツール kubectl。
Google Cloud を操作するシェル環境として Cloud Shell を使用する場合は、これらのツールがインストールされます。
プロジェクトで使用する gcloud CLI が初期化されていることを確認します。
このガイドでは、プロジェクトに roles/owner があることを前提としています。プロジェクトオーナーでない場合は、設定手順を行うために追加の権限が必要になる場合があります。
Google Cloud 外のクラスタの場合、GKE Identity Service はクラスタから Google Identity API を呼び出す必要があります。ネットワークポリシーで送信トラフィックがプロキシを経由する必要があるかどうかを確認します。

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

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

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

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

API を有効にする

ゲートウェイをプロジェクトに追加するには、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 ゲートウェイの Google グループ機能は、GKE Identity Service を使用して Google からグループメンバー情報を取得します。GKE Identity Service の詳細については、GKE Identity Service の概要をご覧ください。

ゲートウェイで GKE クラスタを使用する場合、Google グループのアクセス制御を使用するために GKE Identity Service を設定する必要はありません。代わりに、RBAC 向け Google グループを構成するの手順を行い、Google グループに IAM のロールを付与するに進んで、グループメンバーが Connect ゲートウェイを介してクラスタにアクセスできるようにします。

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 ゲートウェイの Google グループ機能がデフォルトで有効になります。

コンソール

以前にフリートに GKE Identity Service を設定していない場合は、GKE Identity Service のクラスタを構成する手順を行います。

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

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

GKE Enterprise の [機能] に移動
[機能] テーブルの [Identity Service] 行の [詳細] をクリックします。プロジェクトのクラスタの詳細が表示されます。
[ID サービスを更新する] をクリックして、設定ペインを開きます。
構成するクラスタを選択します。個々のクラスタを選択するか、すべてのクラスタを同じ ID 構成にするように指定できます。
[ID プロバイダの構成] セクションで、ID プロバイダを保持、追加、更新、削除することを選択できます。
[続行] をクリックして、次の構成ステップに進みます。この設定に対して少なくとも 1 つの有効なクラスタを選択した場合は、[Google 認証] セクションが表示されます。
選択したクラスタで Google 認証を有効にするには、[有効にする] を選択します。プロキシ経由で Google ID プロバイダにアクセスする必要がある場合は、[プロキシ] の詳細を入力します。
[構成の更新] をクリックします。これにより、選択したクラスタに ID 構成が適用されます。

gcloud

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

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

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

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

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

  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 名前空間に 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 ロールを付与する

ゲートウェイ経由接続されたクラスタを操作には、グループに次の 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 サーバーは、指定したグループからゲートウェイを経由する 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 を使用する方法の例をご覧ください。