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

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

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

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

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

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

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

登録済みの GKE クラスタ
Anthos（GKE Enterprise）バージョン 1.13 以降の VMware 上およびベアメタル上の Google Distributed Cloud（オンプレミス）デプロイのクラスタ
Kubernetes バージョン 1.25 以降の GKE on AWS と GKE on Azure。
バージョン 1.26.0-gke.8、1.27.0-gke.5、1.28.0-gke.2 以降の接続クラスタ。

この機能を使用するためにオンプレミスクラスタのアップグレードが必要な場合は、VMWare でのクラスタのアップグレードとベアメタルでのクラスタのアップグレードをご覧ください。

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

仕組み

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

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

ユーザー alice@example.com をメンバーに含む。
gke-security-groups@example.com のネストされたグループ。

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

ユーザー alice@example.com が Google ID を使用してログインし、コマンドラインからクラスタを使用する場合は、Connect Gateway の使用で説明されているように、クラスタのゲートウェイ kubeconfig を取得します。
ユーザーは、kubectl コマンドを実行するか、Google Cloud コンソールで Google Kubernetes Engine の [ワークロード] または [オブジェクトブラウザ] ページを開いてリクエストを送信します。
リクエストが Connect Service によって受信され、IAM を使用して承認チェックが実行されます。
Connect Service は、クラスタで動作している Connect Agent にリクエストを転送します。このリクエストには、クラスタの認証と認可で使用するためのユーザーの認証情報が含まれています。
Connect Agent が、リクエストを Kubernetes API サーバーに転送します。
Kubernetes API サーバーでリクエストを GKE Identity Service に転送すると、GKE Identity Service でリクエストが検証されます。
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 を呼び出す必要があります。ネットワークポリシーでアウトバウンドトラフィックがプロキシを経由する必要があるかどうかを確認します。

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

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

組織の Google Workspace に gke-security-groups@YOUR-DOMAIN という形式のグループがあることを確認します。そのようなグループがない場合は、組織内でグループを作成するの手順に沿って、Google Workspace 管理コンソールでグループを作成します。
グループを別のグループに追加するの手順に沿って、アクセス制御に使用するグループを 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 グループを構成するの手順に沿って設定し、IAM ロールを付与するの説明に従って、Gateway を介してクラスタへのアクセス権を付与します。

Gateway で GKE 接続クラスタを使用している場合、Google グループのサポートに GKE Identity Service は必要ありません。選択したクラスタタイプに応じた手順に沿って、Google グループのサポートを設定します。

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

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

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

CLUSTER_KUBECONFIG は、クラスタの kubeconfig のパスに置き換えます。

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

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

VMware 上、または Bare Metal 上で Google Distributed Cloud を使用している場合、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 のクラスタを構成するの説明に従って設定します。

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

Google Cloud コンソールで、[機能マネージャー] ページに移動します。

機能マネージャーに移動

[Identity Service] パネルで [詳細] をクリックします。プロジェクトのクラスタの詳細が表示されます。
[Identity Service の更新] をクリックして、設定ペインを開きます。
構成するクラスタを選択します。個々のクラスタを選択するか、すべてのクラスタを同じ ID 構成にするように指定できます。
[Configure Identity Providers] セクションで、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 グループのアクセス権の構成

プロキシ経由で 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 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.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 認証の使用をご覧ください。

次のステップ

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