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

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

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

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

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

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

• GKE on 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: 利用可能なすべてのバージョン。

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

仕組み

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

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

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

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

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

始める前に

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

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 を有効にするために必要なロール

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 を有効にするために必要なロール

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

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

必要なロール

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

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

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

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

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

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

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

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

• Google Cloud上の GKE: RBAC 向け Google グループを構成してから、グループに IAM ロールを付与するセクションに進みます。
• GKE 接続クラスタ:
  • EKS 接続クラスタに接続する
  • AKS 接続クラスタに接続する
  • 他のクラスタタイプに接続する

• Google Distributed Cloud: クラスタの ClientConfig カスタム リソースを更新して、グループのサポートを有効にします。Distributed Cloud は、すべてのクラスタの kube-public Namespace に default という名前の ClientConfig を自動的に作成します。このカスタム リソースが存在することを確認するには、次のコマンドを実行します。

  kubectl --kubeconfig CLUSTER_KUBECONFIG get ClientConfig default -n kube-public
  

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

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

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

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

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

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

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

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

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

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. グループのサポートを有効にするには、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 であることを確認します。

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

次のステップ

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