このドキュメントでは、Google Cloud コンソールで Google Distributed Cloud を管理できるようにする方法について説明します。これには、基本的な管理(クラスタにログインしてワークロードを表示できることなど)と、クラスタをアップグレード、更新、削除できるようにクラスタのライフサイクル管理を有効にする方法が含まれます。
フリート メンバーとコンソール
Google Distributed Cloud はすべてフリートのメンバーである必要があります。フリートは、複数のクラスタとそのワークロードを表示して管理するために統合された方法です。クラスタの各フリートは、フリートホスト プロジェクトに関連付けられています。
Google Distributed Cloud では、クラスタ構成ファイルの gkeConnect
セクションでフリートホスト プロジェクトを指定すると、管理クラスタが作成時にフリートに登録されます。Google Distributed Cloud は、この情報を使用して、クラスタを指定されたフリート プロジェクトに登録します。登録が失敗した場合は、gkectl update credentials register
を実行して登録を再試行できます。
登録を再試行するときは、connect-register サービス アカウント キーを更新する必要はありません。つまり、元の connect-register サービス アカウントを引き続き使用できます。このコマンドの詳細については、サービス アカウント キーのローテーションをご覧ください。
Google Distributed Cloud では、ユーザー クラスタは作成時にフリートに登録されます。
gkectl
を使用してユーザー クラスタを作成する場合は、クラスタ構成ファイルのgkeConnect
セクションでフリートホスト プロジェクトを指定します。Google Distributed Cloud は、この情報を使用して、指定されたフリート プロジェクトにクラスタを登録します。標準ツール(コンソール、Google Cloud CLI、または Terraform)を使用してユーザー クラスタを作成すると、クラスタは自動的に指定したプロジェクトのフリート メンバーになります。
Google Distributed Cloud など、Google Cloud の外部のフリートメンバーは、フリートホスト プロジェクトのコンソールに、Google Cloud 上の GKE などの他のフリート クラスタと一緒に表示されます。コンソールから Google Distributed Cloud を管理できる範囲は、以下の内容によって異なります。
認証を設定している場合は、クラスタにログインしてワークロードや他の詳細を表示できます。
クラスタのクラスタ ライフサイクル管理を有効にしている場合は、コンソールを使用してユーザー クラスタをアップグレード、更新、削除することもできます。この機能が有効になっていない場合は、管理ワークステーションで
gkectl
を使用してクラスタのライフサイクルの管理のみを行えます。
登録済みクラスタを表示する
すべてのフリート クラスタが、コンソールの [Google Kubernetes Engine クラスタの概要] ページに表示されます。これらの両方によって、フリート全体の概要と、Google Distributed Cloud で GKE On-Prem API によって管理されているクラスタを確認できます。
フリート クラスタを表示するには:
コンソールで、Google Kubernetes Engine クラスタの概要ページに移動します。
Google Cloud プロジェクトを選択します。
[タイプ] 列に [vm GKE on VMware] と表示されている場合、クラスタは GKE On-Prem API によって管理されています。
[タイプ] 列に [外部] と表示されている場合は、クラスタが GKE On-Prem API で管理されていません。
クラスタの詳細を表示するには、ユーザーがクラスタにログインして認証する必要があります。そのためには、次のことを行う必要があります。
認証を設定する
前述のように、すべてのフリート クラスタはコンソールの GKE クラスタと GKE Enterprise クラスタのリストに表示されます。ただし、ノードやワークロードなどの詳細を表示する場合や、クラスタのライフサイクル管理タスクを実行するためにこの機能が有効になっている場合は、クラスタにログインして認証する必要があります。これを行うには、登録したクラスタに次のいずれかの認証方法を設定する必要があります。
Google ID: このオプションを選択すると、ユーザーは Google Cloud ID(Google Cloud アカウントに関連付けられているメールアドレス)を使用してログインできます。ユーザーが Google ID で Google Cloud にすでにアクセスできる場合は、このオプションを使用します。コンソールでクラスタを作成した場合は、Google ID を使用してクラスタにログインできますが、他のユーザー用に認証を構成する必要があります。
Google ID でのログインは、コンソールでの認証が最も簡単な方法です。特に、最小限のインストールで Google Distributed Cloud を試す場合は、この設定の詳細を確認してください。詳しくは、後述の Google ID 認証を設定するをご覧ください。
OpenID Connect(OIDC): このオプションを選択すると、ユーザーは、Okta や Microsoft AD FS などのサードパーティの OIDC ID プロバイダからの ID を使用して、コンソールからクラスタにログインできます。このオプションは、プロバイダの既存のユーザー名、パスワード、セキュリティ グループ メンバーがある場合に使用できます。クラスタにサードパーティの OIDC 認証を設定する方法については、次のガイドをご覧ください。
OIDC による GKE Identity Service 用のクラスタを構成する: このガイドでは、クラスタ別にクラスタに OIDC 認証を設定する方法について説明します。
フリート用に GKE Identity Service を設定する: このオプションを選択すると、フリートレベルで OIDC を設定できます。
署名なしトークン: 上記の Google 提供のソリューションが組織に適していない場合は、Kubernetes サービス アカウントとログインする署名なしトークンを使用して認証を設定できます。詳細については、署名なしトークンを使用して設定するをご覧ください。
必要な役割の付与
コンソールへのアクセスは Identity and Access Management(IAM)によって制御されます。これらの IAM ロールは、どの認証方法を使用する場合でも必要です。コンソールでクラスタのライフサイクルを管理するには、一部の IAM ロールを付与する必要があります。
ユーザーがコンソールにアクセスできるようにするには、少なくとも次のロールを付与する必要があります。
roles/container.viewer
。このロールを使用すると、ユーザーはコンソールで GKE クラスタのページやその他のコンテナ リソースを表示できます。このロールに含まれる権限の詳細について、または読み取り / 書き込み権限を持つロールを付与する方法については、IAM のドキュメントの Kubernetes Engine のロールをご覧ください。roles/gkehub.viewer
。このロールでは、ユーザーがコンソールで Google Cloud の外部のクラスタを表示できます。このロールに含まれる権限の詳細について、または読み取り / 書き込み権限を持つロールを付与する方法については、IAM ドキュメントの GKE Hub のロールをご覧ください。
ユーザーがコンソールでクラスタのライフサイクルを管理できるようにするには、
roles/gkeonprem.admin
の IAM ロールを付与します。roles/gkeonprem.admin
ロールを使用すると、GKE On-Prem API に対する管理者権限がユーザーに付与されます。この API により、コンソールでクラスタのライフサイクルを管理できます。このロールに含まれる権限の詳細については、IAM のドキュメントの GKE On-Prem ロールをご覧ください。
次のコマンドでは、コンソールでクラスタのライフサイクルを管理するために必要な最小限のロールを付与する方法を示します。
gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \ --member=MEMBER \ --role=roles/container.viewer gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \ --member=MEMBER \ --role=roles/gkehub.viewer gcloud projects add-iam-policy-binding FLEET_HOST_PROJECT_ID \ --member=MEMBER \ --role=roles/gkeonprem.admin
ここで
FLEET_HOST_PROJECT_ID
は、フリートホスト プロジェクトです。gkectl
を使用して作成されたクラスタの場合、これは、ユーザー クラスタの構成ファイルのgkeConnect
セクションで構成したプロジェクトです。コンソールで作成されたクラスタの場合、これはクラスタの作成時に選択したプロジェクトです。MEMBER
は、user:emailID
形式のユーザーのメールアドレスです(例:user:alice@example.com
)。
コンソールでクラスタのライフサイクル管理を有効にする
標準ツール(コンソール、gcloud CLI、または Terraform)を使用して作成されたユーザー クラスタは、GKE On-Prem API に自動的に登録され、コンソールでクラスタのライフサイクル管理タスクを実行できます。gkectl
を使用して作成したユーザー クラスタでこの機能を有効にする場合は、GKE On-Prem API で管理されるようにユーザー クラスタを構成するに記載されている手順に沿って操作します。クラスタ ライフサイクル管理が有効になっている場合は、コンソールから次のタスクを実行できます。
Google ID 認証を設定する
ユーザーが Google ID を使用してクラスタにログインできるようにするには、以下の内容を構成する必要があります。
Google Cloud コンソールの GKE クラスタリストと GKE Enterprise クラスタリストでクラスタを表示して操作できるようにするには、ユーザーに特定の Identity and Access Management(IAM)ロールが必要です。
コネクト ゲートウェイがコネクト エージェント経由でクラスタの Kubernetes API サーバーにアクセスするために必要な Kubernetes のロールベース アクセス制御(RBAC)ポリシーにユーザーを追加する必要があります。
RBAC 認可を構成する
各クラスタの Kubernetes API サーバーは、コンソールからのリクエストを認可できる必要があります。認可を構成するには、クラスタごとに Kubernetes のロールベース アクセス制御(RBAC)ポリシーを構成する必要があります。
標準ツールを使用してユーザー クラスタを作成した場合は、クラスタへの完全な管理者権限を付与する適切な RBAC ポリシーがすでに付与されている可能性があります。GKE On-Prem API は、次の場合、管理者として Google アカウントに自動的に追加します。
コンソールでユーザー クラスタを作成した。
gcloud CLI を使用してユーザー クラスタを作成し、Google アカウントが cluster create コマンドの
--admin-users
フラグで指定されている。Terraform を使用してユーザー クラスタを作成し、
authorization.admin_users.username
フィールドに Google アカウントを指定している。
gkectl
を使用して作成されたユーザー クラスタでは、コンソールを使用してクラスタを管理するための RBAC ポリシーは付与されません。クラスタの作成後に、自分自身を追加する必要があります。クラスタの作成に使用したツールに関係なく、クラスタの作成後に他のユーザーを管理者として追加できます。
次のいずれかの方法を使用して、クラスタに管理者権限を付与できます。2 つの異なる gcloud
コマンドが用意されています。
gcloud ... generate-gateway-rbac
コマンドは、クラスタの kubeconfig とコンテキスト(通常は管理ワークステーションにのみ存在します)にアクセスする必要があるため、管理ワークステーションで実行する必要があります。generate-gateway-rbac
コマンドを使用すると RBAC ポリシーをカスタマイズできますが、ユーザーのメールアドレスはコンソールの [クラスタの詳細] セクションに管理者として表示されません。gcloud ... update
コマンドは、管理ワークステーション、または GKE On-Prem API にアクセスできる任意のコンピュータで実行できます。
generate-gateway-rbac
管理ワークステーションに接続する。
次のコマンドを実行して、コンポーネントを更新します。
gcloud components update
RBAC ポリシーを生成して、ユーザーとサービス アカウントのクラスタに適用します。
gcloud container fleet memberships generate-gateway-rbac \ --membership=MEMBERSHIP_NAME \ --role=ROLE \ --users=USERS \ --project=FLEET_HOST_PROJECT_ID \ --kubeconfig=KUBECONFIG_PATH \ --context=KUBECONFIG_CONTEXT \ --apply
以下を置き換えます。
- MEMBERSHIP_NAME: 対象のフリートでクラスタを一意に表すために使用される名前。Google Distributed Cloud では、メンバーシップ名とクラスタ名は同じです。
- ROLE: クラスタのユーザーに付与する Kubernetes のロール。ユーザーに、クラスタ内のすべての名前空間ですべてのリソースへの完全アクセス権を付与するには、
clusterrole/cluster-admin
を指定します。読み取り専用アクセス権を付与するには、clusterrole/view
を指定します。また、カスタムロールを作成することもできます(例:role/mynamespace/namespace-reader
)。カスタムロールは、コマンドを実行する前に存在している必要があります。 - USERS: カンマ区切りのリストととして、権限を付与するユーザー(ユーザー アカウントまたはサービス アカウント)のメールアドレス。例:
--users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com
。 - FLEET_HOST_PROJECT_ID: フリート ホスト プロジェクトのプロジェクト ID。
- KUBECONFIG_PATH: クラスタのエントリを含む kubeconfig を格納するローカルパス。
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: /usr/local/google/home/foo/.kube/config, context: kind-kind Writing RBAC policy for user: foo@example.com to cluster. Successfully applied the RBAC policy to cluster.
これは、Connect ゲートウェイを介してクラスタにアクセスするためのコンテキストです。
generate-gateway-rbac
コマンドの詳細については、gcloud CLI リファレンス ガイドをご覧ください。
update
次のコマンドを実行して、コンポーネントを更新します。
gcloud components update
clusterrole/cluster-admin
ロールを付与する必要があるユーザーごとに、--admin-users
フラグを指定して次のコマンドを実行します。1 つのフラグで複数のユーザーを指定することはできません。このコマンドは、コマンドで指定したユーザーで権限付与リストを上書きするため、コマンドには必ず Google アカウントを含めてください。gcloud container vmware clusters update USER_CLUSTER_NAME \ --admin-users YOUR_GOOGLE_ACCOUNT \ --admin-users ADMIN_GOOGLE_ACCOUNT_1 \
このコマンドは、Kubernetes の clusterrole/cluster-admin
ロールを付与するだけでなく、コネクト ゲートウェイを介してクラスタにアクセスするために必要な RBAC ポリシーを付与します。
コンソール
ユーザーに RBAC ポリシーを適用するには、コンソールで次の手順を行います。
コンソールで、Google Kubernetes Engine クラスタの概要ページに移動します。
ユーザー クラスタが存在する Google Cloud プロジェクトを選択します。
クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。
[認可] セクションで [クラスタ管理者ユーザー] フィールドをクリックし、各ユーザーのメールアドレスを入力します。
ユーザーの追加が完了したら、[完了] をクリックします。