Connect Gateway の設定

このガイドは、プロジェクトのユーザーとサービス アカウントが使用するために Connect Gateway を設定する必要があるプラットフォーム管理者を対象としています。この設定により、ユーザーは次のことが可能になります。

  • Google Cloud コンソールを使用して、Google Cloud ID で Google Cloud 以外の登録済みクラスタにログインする。

  • kubectl を使用して、Connect Gateway からクラスタにアクセスする。

この設定では、Google グループのメンバーシップではなく、個人 ID に基づいたユーザーとサービスの認証のみを行えます。追加のグループ サポートを設定するには、Google グループでの Connect Gateway の設定をご覧ください。

Connect Gateway をまだよく理解していない場合は、概要で基本的なコンセプトと仕組みをご覧ください。

始める前に

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

    • Google Cloud とやり取りするためのコマンドライン ツールである、Google Cloud CLI の最新バージョン。
    • Kubernetes クラスタに対してコマンドを実行するために使用する kubectlkubectl をインストールする必要がある場合は、以下の手順に沿ってください。

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

  2. プロジェクトで使用する gcloud CLI を初期化するか、次のコマンドを実行して gcloud CLI を承認し、プロジェクトをデフォルトとして設定します。

    gcloud auth login
    gcloud config set project PROJECT_ID
    

設定に必要な IAM ロール

このガイドでは、プロジェクトに roles/owner 権限があることを前提としています。プロジェクト オーナーでない場合は、次のタスクを行えるようにプロジェクト オーナーに対してプロジェクトへの追加の権限を付与するよう依頼してください。

  • API を有効にするには、Service Usage 管理者ロール(roles/serviceusage.serviceUsageAdmin)に含まれる serviceusage.services.enable 権限が必要です。プロジェクト オーナーは、次のように、serviceusage.services.enable 権限を有効にしてカスタムロールを作成するか、roles/serviceusage.serviceUsageAdmin を付与できます。

    gcloud projects add-iam-policy-binding PROJECT_ID \
       --member user:USER_EMAIL_ADDRESS \
       --role='roles/serviceusage.serviceUsageAdmin'
    
  • ユーザーとサービス アカウントに IAM 権限を付与して、Connect Gateway を使用できるようにするには、プロジェクト IAM 管理者のロール(roles/resourcemanager.projectIamAdmin)が必要です。これは、プロジェクト オーナーが次のコマンドで付与できます。

    gcloud projects add-iam-policy-binding PROJECT_ID \
       --member user:USER_EMAIL_ADDRESS \
       --role='roles/resourcemanager.projectIamAdmin'
    

API を有効にする

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

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

登録済みのクラスタを確認する

プロジェクト フリートに登録されたクラスタだけが、Connect ゲートウェイを使用してアクセスできます。オンプレミスや他のパブリック クラウド上の GKE クラスタは、作成時に自動的に登録されます。ただし、Google Cloud 上の GKE クラスタと接続されたクラスタは、個別に登録する必要があります。クラスタを登録する必要がある場合は、クラスタ登録ガイドの手順に沿ってください。ゲートウェイを使用するには、GKE クラスタをフリートに登録する必要があります。

クラスタが登録されていることを確認するには、次のコマンドを実行します。

gcloud container fleet memberships list

次の出力例のように、登録されているすべてのクラスタのリストが表示されます。

NAME         EXTERNAL_ID
cluster-1    0192893d-ee0d-11e9-9c03-42010a8001c1
cluster-2    f0e2ea35-ee0c-11e9-be79-42010a8400c2

IAM のロールをユーザーに付与する

クラスタへのアクセスは、Identity and Access Management(IAM)によって制御されます。次のセクションで説明するように、kubectl を使用してクラスタにアクセスするために必要な IAM ロールは、Google Cloud コンソールでクラスタにアクセスするロールとは若干異なります。

kubectl を介してアクセスロールを付与する

ユーザーがプロジェクトに roles/owner を持っている場合を除き、kubectl を使用して Connect Gateway を介してクラスタを操作するには、少なくともユーザーとサービス アカウントに次の IAM ロールが必要です。

  • roles/gkehub.gatewayAdmin: このロールにより、ユーザーは Connect Gateway API にアクセスして、kubectl を使用してクラスタを管理できます。

    • ユーザーが、接続されたクラスタに対する読み取り専用アクセス権のみを必要とする場合は、代わりに roles/gkehub.gatewayReader を付与します。

    • ユーザーが接続されたクラスタへの読み取り / 書き込みアクセス権を必要とする場合は、roles/gkehub.gatewayEditor を付与します。

  • roles/gkehub.viewer: このロールを使用すると、ユーザーがクラスタ kubeconfigs を取得できます。

これらのロールに含まれる権限の詳細については、IAM のドキュメントの GKE Hub のロールをご覧ください。

これらのロールは、次のコマンドを使用して付与できます。

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=GATEWAY_ROLE
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=MEMBER \
    --role=roles/gkehub.viewer

ここで

  • MEMBER は、ユーザーまたはサービス アカウントです。形式は user|serviceAccount:emailID です。次に例を示します。

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com
  • GATEWAY_ROLEroles/gkehub.gatewayAdminroles/gkehub.gatewayReaderroles/gkehub.gatewayEditor のいずれかです。

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

Google Cloud コンソールを介してアクセス ロールを付与する

Google Cloud コンソールを使用して Google Cloud の外部でクラスタを操作するには、クラスタを表示するために少なくとも次の IAM ロールが必要です。

  • roles/container.viewer。このロールを使用すると、ユーザーは Google Cloud コンソールで GKE クラスタのページやその他のコンテナ リソースを表示できます。このロールに含まれる権限の詳細については、IAM のドキュメントの Kubernetes Engine のロールをご覧ください。

  • roles/gkehub.viewer。このロールを使用すると、ユーザーは Google Cloud コンソールで Google Cloud 外のクラスタを表示できます。これは、kubectl のアクセスに必要なロールの 1 つです。このロールをすでにユーザーに付与している場合は、再度付与する必要はありません。このロールに含まれる権限の詳細については、IAM のドキュメントの GKE Hub のロールをご覧ください。

    次のコマンドで、PROJECT_ID は、フリートホスト プロジェクトのプロジェクト ID に置き換えます。また、MEMBER は、ユーザーのメールアドレスかサービス アカウント(user|serviceAccount:emailID 形式)に置き換えます。次に例を示します。

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=MEMBER \
        --role=roles/container.viewer
    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member=MEMBER \
        --role=roles/gkehub.viewer
    

IAM ロールの付与について詳しくは、IAM のドキュメントのプロジェクト、フォルダ、組織へのアクセスを管理するをご覧ください。

RBAC 認可を構成する

各クラスタの Kubernetes API サーバーは、Google Cloud コンソールからのリクエストや、指定したユーザーまたはサービス アカウントから Connect ゲートウェイを経由する kubectl コマンドからのリクエストを承認できる必要があります。そのためには、ゲートウェイ経由でアクセスできるようにするクラスタのそれぞれでロールベースのアクセス制御(RBAC)ポリシーを更新する必要があります。次のポリシーを追加または更新する必要があります。

  • 権限借用ポリシー: Connect Agent がユーザーに代わって Kubernetes API サーバーにリクエストを送信することを承認します。
  • 権限ポリシー。クラスタでユーザーに付与する権限を指定します。これは、クラスタレベルのロール(clusterrole/cluster-admin や clusterrole/cloud-console-reader など)か、名前空間レベルのロール(role/default/pod-reader など)です。

(省略可)cloud-console-reader ロールを作成する

Google Cloud コンソールでクラスタ リソースにアクセスするには、認証済みユーザーに関連する Kubernetes 権限が必要です。それらのユーザーにクラスタ管理者などのより広範な権限を付与しない場合は、クラスタのノード、永続ボリューム、Pod、ストレージ クラスを表示するために必要な最小限の権限を含むカスタム RBAC ロールを作成します。この一連の権限を定義するには、クラスタに ClusterRole RBAC リソース(cloud-console-reader)を作成します。

cloud-console-reader は、クラスタのノード、永続ボリューム、Pod、ストレージ クラスに対する getlistwatch の権限をユーザーに付与し、それによってユーザーはこれらのリソースに関する詳細情報を表示できます。

kubectl

cloud-console-reader ClusterRole を作成してクラスタに適用するには、次のコマンドを実行します。

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

次に、権限ポリシーを設定するときに、このロールをユーザーに付与できます。次のセクションで説明します。

必要な RBAC ポリシーを作成して適用する

必要な RBAC ポリシーを作成して適用する方法を次に示します。これを行う最も簡単な方法は、gcloud CLI を使用して、ユーザーのために適切なポリシーを生成して適用することです。また、よろしければ、RBAC ポリシー ファイルを作成し、kubectl を使用して適用することもできます。

gcloud

gcloud CLI を使用し、選択したクラスタにポリシーを生成して適用するには、次のコマンドを実行します。

gcloud container fleet memberships generate-gateway-rbac  \
    --membership=MEMBERSHIP_NAME \
    --role=ROLE \
    --users=USERS \
    --project=PROJECT_ID \
    --kubeconfig=KUBECONFIG_PATH \
    --context=KUBECONFIG_CONTEXT \
    --apply

次のように置き換えます。

  • MEMBERSHIP_NAME: そのフリートでクラスタを一意に表すために使用される名前。クラスタのメンバーシップ名を確認する方法については、フリートのメンバーシップ登録状況を取得するをご覧ください。
  • ROLE: クラスタのユーザーに付与する Kubernetes のロール(例: clusterrole/cluster-adminclusterrole/cloud-console-readerrole/mynamespace/namespace-reader)。このロールは、コマンドを実行する前に存在している必要があります。
  • USERS: カンマ区切りのリストととして、権限を付与するユーザー(ユーザー アカウントまたはサービス アカウント)のメールアドレス。例: --users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com
  • PROJECT_ID: クラスタが登録されているプロジェクト ID。
  • KUBECONFIG_PATH: クラスタのエントリを含む kubeconfig を格納するローカル ファイルパス。 ほとんどの場合、$HOME/.kube/config です。
  • KUBECONFIG_CONTEXT: kubeconfig ファイルに含まれる、クラスタの内容。現在の内容は、kubectl config current-context を実行してコマンドラインから取得できます。現在の内容を使用するかどうかに関係なく、次のような単純なコマンドを実行して、クラスタへのアクセスに適していることを確認します。

    kubectl get namespaces \
      --kubeconfig=KUBECONFIG_PATH \
      --context=KUBECONFIG_CONTEXT
    

gcloud container fleet memberships generate-gateway-rbac を実行すると、出力の最後に次のように表示されます。

connectgateway_example-project-12345_global_example-membership-name

これは、Connect Gateway を介してクラスタにアクセスするためのコンテキストです。

generate-gateway-rbac コマンドの詳細については、gcloud CLI リファレンス ガイドをご覧ください。

このコマンドの実行時に ERROR: (gcloud.container.hub.memberships) Invalid choice: 'generate-gateway-rbac' などのエラーが発生した場合は、更新ガイドに沿って Google Cloud CLI を更新してください。

kubectl

次の例では、ユーザー(foo@example.com)とサービス アカウント(test@example-project.iam.gserviceaccount.com)に適切なポリシーを作成して両方にクラスタに対する cluster-admin 権限を付与し、ポリシー ファイルを /tmp/gateway-rbac.yaml として保存する方法を示します。その後、ポリシーは、現在のコンテキストに関連付けられたクラスタに適用されます。

cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: gateway-impersonate
rules:
- apiGroups:
  - ""
  resourceNames:
  - foo@example.com
  - test@example-project.iam.gserviceaccount.com
  resources:
  - users
  verbs:
  - impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-impersonate
roleRef:
  kind: ClusterRole
  name: gateway-impersonate
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: connect-agent-sa
  namespace: gke-connect
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin
subjects:
- kind: User
  name: foo@example.com
- kind: User
  name: test@example-project.iam.gserviceaccount.com
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply policies to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH  -f /tmp/gateway-rbac.yaml

RBAC 権限の指定についての詳細は、RBAC 認可を使用するをご覧ください。

VPC Service Controls のサポート

VPC Service Controls によって、Identity and Access Management(IAM)から独立している Google Cloud サービスに対するセキュリティが強化されます。IAM では詳細な ID ベースのアクセス制御が可能ですが、VPC Service Controls では、境界全体での下り(外向き)データの制御など、より広範なコンテキスト ベースの境界セキュリティが可能になります。たとえば特定のプロジェクトのみが BigQuery データにアクセスできるように指定できます。VPC Service Controls によるデータ保護の仕組みについて詳しくは、VPC Service Controls の概要をご覧ください。

VPC Service Controls と Connect Gateway を併用すると、ゲートウェイを使用するために必要な API が指定したサービス境界内からアクセスでき、データのセキュリティを高められます。

次のステップ

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