Connect Gateway を設定する
このガイドは、プロジェクトのユーザーとサービス アカウントが使用できるように Connect Gateway を設定する必要のあるプラットフォーム管理者を対象としています。この設定により、ユーザーは次のことが可能になります。
Google Cloud コンソールを使用して、Google Cloud ID で Google Cloud 以外の登録済みクラスタにログインする。
kubectlを使用して、Connect Gateway からクラスタにアクセスする。
この設定では、Google グループのメンバーシップではなく、個人 ID に基づいたユーザーとサービスの認証のみを行えます。追加のグループ サポートを設定するには、Google グループでの Connect Gateway の設定をご覧ください。
Connect Gateway をまだよく理解していない場合は、概要で基本的なコンセプトと仕組みをご覧ください。
始める前に
次のコマンドライン ツールがインストールされていることを確認します。
- Google Cloud CLI の最新バージョン。Google Cloud の操作に使用するコマンドライン ツールです。
kubectl。Kubernetes クラスタにコマンドを実行するために使用します。kubectlをインストールする必要がある場合は、こちらの説明に従ってインストールしてください。
Google Cloud を操作するシェル環境として Cloud Shell を使用している場合は、これらのツールがインストールされています。
プロジェクトで使用する 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 を有効にする
Gateway をプロジェクトに追加するには、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 Gateway を使用してアクセスできます。オンプレミスや他のパブリック クラウド上の GKE クラスタは、作成時に自動的に登録されます。ただし、Google Cloud 上の GKE クラスタと接続されたクラスタは、個別に登録する必要があります。クラスタを登録する必要がある場合は、クラスタ登録ガイドの手順に沿ってください。Gateway を使用するには、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.comserviceAccount:test_sa@example-project.iam.gserviceaccount.com
GATEWAY_ROLEは、roles/gkehub.gatewayAdmin、roles/gkehub.gatewayReader、roles/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のアクセスに必要なロールの一つです。このロールをすでにユーザーに付与している場合は、再度付与する必要はありません。このロールに含まれる権限の詳細については、IAM のドキュメントの GKE Hub のロールをご覧ください。次のコマンドで、
PROJECT_IDは、フリートホスト プロジェクトのプロジェクト ID に置き換えます。また、MEMBERは、ユーザーのメールアドレスかサービス アカウント（user|serviceAccount:emailID形式）に置き換えます。次に例を示します。user:alice@example.comserviceAccount: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 Gateway を経由する kubectl コマンドからのリクエストを承認できる必要があります。そのためには、Gateway 経由でアクセスできるようにするクラスタのそれぞれで、ロールベース アクセス制御（RBAC）ポリシーを更新する必要があります。次のポリシーを追加または更新する必要があります。
- 権限借用ポリシー: Connect Agent がユーザーに代わって Kubernetes API サーバーにリクエストを送信することを承認します。
- 権限ポリシー。クラスタでユーザーに付与する権限を指定します。これは、クラスタレベルのロール（
clusterrole/cluster-adminやclusterrole/cloud-console-readerなど）か、Namespace レベルのロール（role/default/pod-readerなど）です。
（省略可）cloud-console-reader ロールを作成する
Google Cloud コンソールでクラスタ リソースにアクセスする認証済みユーザーは、関連する Kubernetes 権限を持っている必要があります。そうしたユーザーにクラスタ管理者などのより広範な権限を付与しない場合は、クラスタのノード、永続ボリューム、Pod、ストレージ クラスを表示するために必要な最小限の権限を含むカスタム RBAC ロールを作成します。この一連の権限を定義するには、クラスタに ClusterRole RBAC リソース（cloud-console-reader）を作成します。
cloud-console-reader は、クラスタのノード、永続ボリューム、Pod、ストレージ クラスに対する get、list、watch の権限をユーザーに付与し、これらのリソースの詳細情報を確認できるようにします。
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-admin、clusterrole/cloud-console-reader、role/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 を実行すると、出力の最後に次のような文字列が表示されます（読みやすさのために短くしています）。
Validating input arguments. Specified Cluster Role is: clusterrole/cluster-admin Generated RBAC policy is: -------------------------------------------- ... --- Applying the generate RBAC policy to cluster with kubeconfig: artifacts/kubeconfig, context: example-cluster-admin@example-cluster Writing RBAC policy for user: 222larabrown@gmail.com to cluster. Successfully applied the RBAC policy to cluster.
これは、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 を併用すると、Gateway を使用するために必要な API が指定したサービス境界内からアクセスでき、データのセキュリティを高められます。
次のステップ
- Connect Gateway を使用して、コマンドラインからクラスタに接続する方法を学習する。
- Cloud Build との統合のチュートリアルで、DevOps 自動化の一環として Connect Gateway を使用する方法の例を確認する。