このドキュメントでは、Google Distributed Cloud ソフトウェアで作成された Bare Metal 上の管理者クラスタとユーザー クラスタを Google Cloud コンソールで管理できるようにする方法について説明します。クラスタ管理機能には、クラスタへのログイン、ワークロードの表示、クラスタのアップグレード、更新、削除などがあります。
フリート メンバーとコンソール
すべてのクラスタは、複数のクラスタとそのワークロードを表示して管理するための統合された方法であるフリートのメンバーである必要があります。クラスタの各フリートは、フリートホスト プロジェクトに関連付けられています。
すべてのクラスタは、作成時にフリートに登録されます。
bmctlを使用してクラスタを作成する場合は、クラスタ構成ファイルのgkeConnectセクションでフリートホスト プロジェクトを指定します。クラスタは、指定されたプロジェクトのフリート メンバーになります。標準の GKE On-Prem API クライアント（コンソール、Google Cloud CLI、Terraform）を使用して管理クラスタまたはユーザー クラスタを作成すると、クラスタは指定されたプロジェクトのフリート メンバーになります。
Google Distributed Cloud など、Google Cloud の外部のフリート メンバーは、フリートホスト プロジェクトのコンソールに、Google Cloud 上の GKE などの他のフリート クラスタと一緒に表示されます。コンソールからベアメタル クラスタを管理できる範囲は、以下の要因によって異なります。
認証を設定している場合は、クラスタにログインしてワークロードや他の詳細を表示できます。
クラスタのクラスタ ライフサイクル管理を有効にしている場合は、コンソールを使用して管理クラスタとユーザー クラスタをアップグレードできます。また、コンソールを使用してユーザー クラスタを更新、削除することもできます。この機能が有効になっていない場合は、管理ワークステーションで
bmctlを使用してクラスタのライフサイクルの管理のみを行えます。
登録済みクラスタを表示する
すべてのクラスタは、コンソールの [GKE クラスタ] ページに表示されます。これらの両方によって、フリート全体の概要と、Google Distributed Cloud で GKE On-Prem API によって管理されているクラスタを確認できます。
フリート クラスタを表示するには:
コンソールで、Google Kubernetes Engine クラスタの概要ページに移動します。
Google Cloud プロジェクトを選択します。
ベアメタルが [タイプ] 列に表示されている場合、クラスタは GKE On-Prem API によって管理されています。 GKE On-Prem API で管理できるのは、管理クラスタとユーザー クラスタのみです。
[タイプ] 列に [外部] と表示されている場合は、クラスタが GKE On-Prem API で管理されていません。
クラスタの詳細を表示するには、クラスタにログインして認証する必要があります。そのためには、次の手順を行います。
認証を設定する
前述したように、すべてのクラスタは、コンソールの GKE クラスタページに表示されます。ただし、ノードやワークロードなどの詳細を表示する場合や、クラスタのライフサイクル管理タスクを実行するためにこの機能が有効になっている場合は、クラスタにログインして認証する必要があります。これを行うには、クラスタに次のいずれかの認証方法を設定する必要があります。
Google ID: このオプションを選択すると、Google Cloud identity（Google Cloud アカウントに関連付けられているメールアドレス）を使用してログインできます。ユーザーが Google ID で Google Cloud にすでにアクセスできる場合は、このオプションを使用します。コンソールでクラスタを作成した場合は、Google ID を使用してクラスタにログインできますが、他のユーザー用に認証を構成する必要があります。
Google ID でのログインは、コンソールでの認証が最も簡単な方法です。この設定方法の詳細は、以下の 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 ロールを付与する必要があります。
ユーザーがコンソールにアクセスできるようにするには、少なくとも次のロールを付与する必要があります。
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 PROJECT_ID \
--member=MEMBER \
--role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=roles/gkehub.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=roles/gkeonprem.admin
ここで
PROJECT_IDは、フリートホスト プロジェクトです。bmctlを使用して作成されたクラスタの場合、これは、ユーザー クラスタの構成ファイルのgkeConnectセクションで構成したプロジェクトです。コンソールで作成されたクラスタの場合、これはクラスタの作成時に選択したプロジェクトです。MEMBERは、user:emailID形式のユーザーのメールアドレスです（例:user:alice@example.com）。
コンソールでクラスタのライフサイクル管理を有効にする
標準ツール（コンソール、gcloud CLI、または Terraform）を使用して作成された管理クラスタとユーザー クラスタは、GKE On-Prem API に自動的に登録されます。これにより、コンソールでクラスタのライフサイクル管理タスクを実行できます。Google Distributed Cloud 1.16 以降では、bmctl を使用してユーザー クラスタと管理クラスタを作成すると、デフォルトで GKE On-Prem API に登録されます。GKE On-Prem API にクラスタを登録する必要がある場合は、GKE On-Prem API で管理されるクラスタを構成するの手順を行います。
Google ID 認証を設定する
ユーザーが Google ID を使用してクラスタにログインできるようにするには、以下の内容を構成する必要があります。
コンソールの [GKE クラスタ] ページでクラスタを表示して操作できるようにするには、ユーザーに特定の Identity and Access Management（IAM）ロールが必要です。
コネクト ゲートウェイがコネクト エージェントを使用してクラスタの Kubernetes API サーバーにアクセスするために必要な Kubernetes のロールベース アクセス制御（RBAC）ポリシーにユーザーを追加する必要があります。
RBAC 認可を構成する
各クラスタの Kubernetes API サーバーは、コンソールからのリクエストを認可できる必要があります。認可を構成するには、クラスタごとにユーザーに Kubernetes のロールベース アクセス制御（RBAC）ポリシーを構成する必要があります。次の場合、Google アカウントは、ユーザー クラスタに対する完全アクセス権を持つ管理者として追加されます。
コンソールでユーザー クラスタを作成した。
gcloud CLI を使用してユーザー クラスタを作成し、Google アカウントが cluster create コマンドの
--admin-usersフラグで指定されている。Terraform を使用してユーザー クラスタを作成し、Google アカウントが
authorization.admin_users.usernameフィールドで指定されている。bmctlを使用してユーザー クラスタを作成し、clusterSecurity.authorization.clusterAdmin.gcpAccounts で Google アカウントを構成している。
クラスタの作成後に、他のユーザーを管理者として追加できます。次のいずれかの方法を使用して、クラスタに管理者権限を付与できます。2 つの異なる gcloud コマンドが用意されています。
gcloud ... generate-gateway-rbacコマンドは、クラスタの kubeconfig とコンテキスト（通常は管理ワークステーションにのみ存在します）にアクセスする必要があるため、管理ワークステーションで実行する必要があります。generate-gateway-rbacコマンドを使用すると RBAC ポリシーをカスタマイズできますが、ユーザーのメールアドレスはコンソールの [クラスタの詳細] セクションに管理者として表示されません。gcloud ... updateコマンドは、管理ワークステーション、または GKE On-Prem API にアクセスできる任意のコンピュータで実行できます。
Google Cloud コンソールで管理クラスタを作成した場合、クラスタへの読み取り専用アクセス権が付与されます。clusterrole/cluster-admin ロールの付与を希望する場合、そのロールを持つユーザーに gcloud ... generate-gateway-rbac コマンドを使用して追加してもらう必要があります。
generate-gateway-rbac
RBAC ポリシーをユーザーに適用するには、管理ワークステーションで次の手順を行います。
次のコマンドを実行してコンポーネントを更新します（必要な場合）。
gcloud components updateRBAC ポリシーを生成して、ユーザーとサービス アカウントのクラスタに適用します。
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: 対象のフリートでクラスタを一意に表すために使用される名前。Google Distributed Cloud では、メンバーシップ名とクラスタ名は同じです。
- ROLE: クラスタのユーザーに付与する Kubernetes のロール。ユーザーに、クラスタ内のすべての名前空間ですべてのリソースへの完全アクセス権を付与するには、
clusterrole/cluster-adminを指定します。読み取り専用アクセスを与えるには、clusterrole/viewを指定します。アクセスを制限するには、カスタムロールを作成します（例:role/mynamespace/namespace-reader）。カスタムロールは、コマンドを実行する前に存在している必要があります。 - USERS: カンマ区切りのリストととして、権限を付与するユーザー（ユーザー アカウントまたはサービス アカウント）のメールアドレス。例:
--users=222larabrown@gmail.com,test-acct@test-project.iam.gserviceaccount.com。 - 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 updateclusterrole/cluster-adminロールを付与する必要があるユーザーごとに、--admin-usersフラグを指定して次のコマンドを実行します。1 つのフラグで複数のユーザーを指定することはできません。このコマンドは、コマンドで指定したユーザーで権限付与リストを上書きするため、コマンドには必ず Google アカウントを含めてください。gcloud container bare-metal clusters update USER_CLUSTER_NAME \ --admin-users YOUR_GOOGLE_ACCOUNT \ --admin-users ADMIN_GOOGLE_ACCOUNT_1 \
このコマンドは、Kubernetes の clusterrole/cluster-admin ロールを付与するだけでなく、コネクト ゲートウェイを介してクラスタにアクセスするために必要な RBAC ポリシーを付与します。
bmctl
ユーザーに RBAC ポリシーを適用するには、管理ワークステーションで次の手順を行います。
clusterSecurity.authorizationセクションをクラスタ構成ファイルに追加します。ご自分のメールアドレスと、クラスタを管理する必要がある他のユーザーのメールアドレスを指定します。次に例を示します。... clusterSecurity: authorization: clusterAdmin: gcpAccounts: [alex@example.com,hao@example.com,sasha@example.com] ...クラスタを更新します。
bmctl update cluster \ -c CLUSTER_NAME \ --kubeconfig=KUBECONFIG次のように変更します。
- CLUSTER_NAME は、更新するクラスタの名前に置き換えます。
- クラスタが自己管理クラスタ（管理クラスタやスタンドアロン クラスタなど）の場合、KUBECONFIG はクラスタの kubeconfig ファイルへのパスに置き換えます。クラスタがユーザー クラスタの場合は、KUBECONFIG は管理クラスタの kubeconfig ファイルへのパスに置き換えます。
コンソール
ユーザーに RBAC ポリシーを適用するには、コンソールで次の手順を行います。
コンソールで、Google Kubernetes Engine クラスタの概要ページに移動します。
ユーザー クラスタが存在する Google Cloud プロジェクトを選択します。
クラスタリストでクラスタの名前をクリックし、[詳細] パネルの [詳細を表示] をクリックします。
[認可] セクションで [管理者ユーザー] フィールドをクリックし、各ユーザーのメールアドレスを入力します。
ユーザーの追加が完了したら、[完了] をクリックします。