Google で OpenID Connect(OIDC)を OpenID プロバイダとして使用し、ユーザー クラスタに対する認証を行うように Anthos clusters on VMware(GKE On-Prem)を構成する方法について説明します。このページでは、Google を OpenID プロバイダとして構成する方法を理解するための一般的なプロセスを説明します。
Anthos clusters on VMware 認証フローの概要については、認証をご覧ください。他の OpenID プロバイダで OIDC を構成する方法については、次のリソースをご覧ください。
Anthos clusters on VMware は、ユーザー クラスタの Kubernetes API サーバーとやり取りする認証方法の 1 つとして OIDC をサポートしています。OIDC を使用すると、組織内のユーザー アカウントの作成、有効化、無効化の標準的な手順を使用して、Kubernetes クラスタへのアクセスを管理できます。
ユーザーがアカウントの承認を得る方法は 2 つあります。
Google Cloud CLI を使用して OIDC フローを開始し、ブラウザベースの同意ページからユーザー認可を取得します。
Google Cloud Console を使用して OIDC 認証フローを開始する。
準備
このトピックは、次の認証と OpenID のコンセプトを理解していることを前提としています。
Google OpenID プロバイダはグループをサポートしていません。Kubernetes のロールベースのアクセス制御(RBAC)を使用して認証済みユーザーにロールを付与する場合は、グループではなく個々のユーザーにロールを付与します。
ヘッドレス システムはサポートされていません。ブラウザベースの認証フローが使用されて、プロンプトで同意が求められ、ユーザー アカウントを承認します。
Google Cloud Console で認証するには、OIDC 認証用に構成する各クラスタを Google Cloud に登録する必要があります。
ペルソナ
このトピックでは、次の 3 つのペルソナについて説明します。
組織管理者。OpenID プロバイダを選択し、クライアント アプリケーションをプロバイダに登録します。
クラスタ管理者。1 つ以上のユーザー クラスタを作成し、クラスタを使用するデベロッパー用の認証構成ファイルを作成します。
デベロッパー。1 つ以上のクラスタでワークロードを実行し、OIDC を使用して認証します。
リダイレクト URL の作成
このセクションは、組織管理者を対象としています。
OpenID プロバイダが ID トークンを返すために使用できる gcloud CLI と Google Cloud コンソール両方のリダイレクト URL を作成する必要があります。
gcloud CLI のリダイレクト URL
Google Cloud CLI は各デベロッパーのローカルマシンにインストールされ、gcloud CLI を含んでいます。1024 より大きいポート番号を指定して、リダイレクト URL に使用できます。
http://localhost:PORT/callback
PORT
はポート番号に置き換えてください。
Google OpenID プロバイダを構成する場合、リダイレクト URL の 1 つとして http://localhost:PORT/callback
を指定します。
Google Cloud コンソールのリダイレクト URL
Google Cloud コンソールのリダイレクト URL は次のとおりです。
https://console.cloud.google.com/kubernetes/oidc
Google OpenID プロバイダを構成する場合、リダイレクト URL の 1 つとして https://console.cloud.google.com/kubernetes/oidc
を指定します。
同意画面の構成
このセクションでは、Google の OAuth 同意画面を構成します。組織内の開発者がユーザー クラスタの認証を開始すると、この同意画面が表示されます。その際、Google に ID を証明し、OAuth クライアントに識別情報を提供するトークンを作成する権限を Google に付与します。このトピックのコンテキストにおいて、OAuth クライアントとは、gcloud CLI または Google Cloud コンソールのいずれかです。
Google Cloud コンソールの [OAuth 同意画面] ページに移動します。
[内部] を選択し、[作成] をクリックします。
[アプリケーションの種類] で [内部] を選択します。
[アプリケーション名] に任意の名前を入力します。例:
GKE on-prem
。[承認済みドメイン] で
google.com
を追加します。必要に応じて、追加のフィールドを入力します。
[保存] をクリックします。
クライアント アプリケーションを Google に登録する
このセクションでは、組織内のデベロッパーの OpenID プロバイダとして Google が機能できるように、Anthos clusters on VMware を Google に登録します。登録の一環として、以前作成した 2 つのリダイレクト URL を指定する必要があります。
Google Cloud Console の [認証情報] ページに移動します。
[認証情報を作成] をクリックし、[OAuth クライアント ID] を選択します。
[アプリケーションの種類] で [ウェブ アプリケーション] を選択します。
[名前] に任意の名前を入力します。
[承認済みのリダイレクト URI] の下に、2 つのリダイレクト URL を追加します。前に作成した gcloud CLI のリダイレクト URL と Google Cloud コンソールのリダイレクト URL を使用します。
[作成] をクリックします。
クライアント ID とクライアント シークレットが表示されます。後で使用するため、保存しておきます。
Anthos clusters on VMware クラスタでの oidc
の構成
このセクションは、クラスタ管理者を対象としています。
OIDC 認証を構成するには、ユーザー クラスタの ClientConfig CRD にクラスタの認証詳細を構成する必要があります。これを行うには、kube-public
Namespace でタイプ clientconfig
の KRM デフォルト オブジェクトを編集します。
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig default
ClientConfig CRD の詳細は、Google Cloud コンソールと Anthos 用の Authentication プラグインの両方に OIDC を構成するために使用されます。構成には、次の OIDC 情報が含まれています。
authentication: - name: NAME_STRING oidc: certificateAuthorityData: CERTIFICATE_STRING clientID: CLIENT_ID clientSecret: CLIENT_SECRET cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc" deployCloudConsoleProxy: PROXY_BOOLEAN extraParams: EXTRA_PARAMS groupsClaim: GROUPS_CLAIM groupPrefix: GROUP_PREFIX issuerURI: ISSUER_URI kubectlRedirectURI: KUBECTL_REDIRECT_URI scopes: SCOPES userClaim: USER_CLAIM userPrefix: USER_PREFIX proxy: PROXY_URL
次の表では、ClientConfig CRD oidc
オブジェクトの各フィールドに入力する方法について説明します。ClientConfig CRD oidc
オブジェクトの一般的な情報については、Anthos clusters on VMware での OIDC の構成をご覧ください。
項目 | 必須 | 説明 | 形式 |
---|---|---|---|
name | ○ | 作成する OIDC 構成の名前。 | 文字列 |
certificateAuthorityData | × |
例: この値は、バージョン 1.4 と 1.5 では省略可能です。この値は、バージョン 1.6.1 以降では省略可能です。ただし、この値は 1.6.0 では必須です。この値は、1.5 から 1.6.0 へのアップグレードにおいて特に重要です。詳細については、1.6.0 リリースノートで既知の問題をご確認ください。 |
文字列 |
clientID | ○ | OpenID プロバイダへの認証リクエストを行うクライアント アプリケーションの ID。gcloud CLI と Google Cloud コンソールの両方でこの ID が使用されます。この ID は、Google にクライアント アプリケーションを登録したときに渡されました。 |
文字列 |
clientSecret | × | クライアント アプリケーション用の Secret。gcloud CLI と Google Cloud コンソールの両方でこのシークレットが使用されます。 この ID は、Google にクライアント アプリケーションを登録したときに渡されました。 | 文字列 |
extraParams | × | "prompt=consent,access_type=offline" に設定します。
|
カンマ区切りのリスト |
groupsClaim | × | 空白のままにします。 | 文字列 |
groupPrefix | × | 空白のままにします。 | 文字列 |
issuerURI | ○ | "https://accounts.google.com" に設定します。クライアント アプリケーション(gcloud CLI や Google Cloud コンソールなどの)で、この URL に認証リクエストを送信します。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。 |
URL 文字列 |
kubectlRedirectURI | ○ | gcloud CLI 用に以前に構成したリダイレクト URL。 | URL 文字列 |
scopes | ○ | OpenID プロバイダに送信する追加のスコープ。「email」に設定します。 | カンマ区切りのリスト |
userClaim | × | 「email」に設定します。 | 文字列 |
userPrefix | × | 既存の名前と競合しないように、ユーザー名のクレームの先頭に付加される接頭辞。このフィールドを指定せず、username が email 以外の値の場合、接頭辞はデフォルトの issuerurl# になります。値 - を使用すると、すべての接頭辞を無効にできます。 |
文字列 |
proxy | × | auth メソッドに使用するプロキシ サーバー(該当する場合)。例: http://user:password@10.10.10.10:8888 |
文字列 |
ユーザー クラスタの RBAC ポリシーを作成する
このセクションは、クラスタ管理者を対象としています。
クラスタを作成したら、Kubernetes ロールベースのアクセス制御(RBAC)を使用して、認証済みクラスタ ユーザーにアクセスを許可します。特定の名前空間内のリソースへのアクセス権を付与するには、Role と RoleBinding を作成します。クラスタ全体のリソースへのアクセス権を付与するには、ClusterRole と ClusterRoleBinding を作成します。
Google を OpenID プロバイダとして使用する場合は、個々のユーザーにアクセス権を付与する必要があります。グループにアクセス権を付与することはできません。これは、Google OpenID プロバイダが返すトークンに、個人ユーザーが属するグループに関する情報がないためです。
たとえば、jane@example.com にクラスタ全体のすべての Secret オブジェクトの表示を許可するとします。
secret-viewer
という ClusterRole のマニフェストは次のとおりです。このロールを付与されたユーザーは、クラスタ内の Secret に対して get、watch、list オペレーションを行えます。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-viewer rules: - apiGroups: [""] # The resource type for which access is granted resources: ["secrets"] # The permissions granted by the ClusterRole verbs: ["get", "watch", "list"]
people-who-view-secrets
という ClusterRoleBinding のマニフェストは次のとおりです。このバインディングは、jane@example.com
というユーザーに secret-viewer
ロールを付与します。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: people-who-view-secrets subjects: - kind: User name: jane@example.com apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-viewer apiGroup: rbac.authorization.k8s.io
ClusterRole を作成するには、マニフェストを secret-viewer-cluster-role.yaml
というファイルに保存し、次のコマンドを入力します。
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role.yaml
ここで、[USER_CLUSTR_KUBECONFIG] はユーザー クラスタの kubeconfig ファイルです。
ClusterRoleBinding を作成するには、マニフェストを secret-viewer-cluster-role-binding.yaml
というファイルに保存し、次のコマンドを入力します。
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role-binding.yaml
認証構成ファイルを作成して配布する
このセクションは、クラスタ管理者を対象としています。
ユーザー クラスタを作成した後、そのクラスタの認証構成ファイルを作成します。1 つの認証構成ファイルで複数のクラスタを構成できます。各認証構成ファイルを、それぞれのクラスタで認証を行うユーザーに提供する必要があります。
認証構成ファイルの作成
現在のディレクトリに認証構成ファイルを作成するには、次の gkectl
コマンドを実行します。
gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG
USER_CLUSTER_KUBECONFIG
は、ユーザー クラスタの kubeconfig
ファイルのパスに置き換えます。gkectl create cluster
を実行してユーザー クラスタを作成したときに、kubeconfig
ファイルが作成されています。
結果: 現在のディレクトリに kubectl-anthos-config.yaml
という名前の認証構成ファイルが作成されます。
認証構成ファイルへの複数のクラスタの追加
複数のクラスタの認証構成の詳細を、1 つの認証構成ファイルに保存できます。
次のコマンドを使用して、追加のユーザー クラスタ認証の詳細を既存の認証構成ファイルに結合できます。既存の認証構成ファイルがある場合、追加のユーザー クラスタ認証の詳細を結合または組み合わせることができます。
- 追加のユーザー クラスタ認証の詳細を、既存の認証構成ファイルに結合する。
- 追加のユーザー クラスタ認証の詳細を組み合わせて、新しいファイルを作成する。
たとえば、組織内の複数のユーザー グループのアクセスニーズに対応するために、anthos-config-1cluster.yaml
と anthos-config-3clusters.yaml
の両方の認証構成ファイルを管理する必要があります。
既存の認証構成ファイルにユーザー クラスタを追加するには:
各クラスタの名前が一意であることを確認します。クラスタの名前が同じ場合は、同じ認証構成ファイルに結合できません。クラスタを作成した後は、そのクラスタの名前を変更できません。
次の
gkectl
コマンドを実行して、構成の詳細を結合するか、組み合わせます。gkectl create-login-config --kubeconfig USER_CLUSTER_KUBECONFIG \ --merge-from IN_AUTH_CONFIG_FILE --output OUT_AUTH_CONFIG_FILE
次のように置き換えます。
USER_CLUSTER_KUBECONFIG
には、追加するユーザー クラスタのkubeconfig
ファイルを指定します。IN_AUTH_CONFIG_FILE
には、追加のクラスタ情報と統合する既存の認証構成ファイルのパスを指定します。OUT_AUTH_CONFIG_FILE
には、結合された認証構成を保存するファイルのパスを指定します。- 追加のクラスタ情報を既存のファイルに統合するには、
IN_AUTH_CONFIG_FILE
と同じファイルを指定します。 - 認証構成の詳細を組み合わせて新しいファイルを作成するには、新しいパスとファイル名を指定します。
- 追加のクラスタ情報を既存のファイルに統合するには、
認証構成ファイルの配布
ユーザーがユーザー クラスタに対して認証を行えるようにするには、作成した 1 つ以上の認証構成ファイルにユーザーがアクセスできるようにします。以下の手順では、gcloud CLI で想定されているデフォルトのファイル名と場所を使用します。別のファイル名と場所の使用については、カスタム構成をご覧ください。
次の方法で認証構成ファイルを配布することを検討してください。
アクセス可能な URL でファイルをホスティングする。
--login-config
フラグをgcloud anthos auth login
コマンドに含めると、gcloud CLI はその場所から認証構成ファイルを取得します。安全なホストでファイルをホスティングすることを検討してください。PEM 証明書を使用して安全な HTTPS アクセスを確立する方法については、gcloud CLI の
--login-config-cert
フラグをご覧ください。各ユーザーにファイルを手動で配布する。ユーザーがファイルをダウンロードしたら、gcloud CLI が想定するデフォルトのファイル名でデフォルトの場所にファイルを保存する方法を指示する必要があります。
たとえば、ユーザーは次のコマンドを実行して、デフォルトのファイル名
kubectl-anthos-config.yaml
でデフォルトの場所に、認証構成ファイルを格納できます。Linux
mkdir -p $HOME/.config/google/anthos/ cp AUTH_CONFIG_FILE $HOME/.config/google/anthos/kubectl-anthos-config.yaml
ここで、
AUTH_CONFIG_FILE
は認証構成ファイルの名前です。例:kubectl-anthos-config.yaml
。macOS
mkdir -p $HOME/Library/Preferences/google/anthos/ cp AUTH_CONFIG_FILE $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
ここで、
AUTH_CONFIG_FILE
は認証構成ファイルの名前です。例:kubectl-anthos-config.yaml
。Windows
md "%APPDATA%\google\anthos" copy AUTH_CONFIG_FILE "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"
ここで、
AUTH_CONFIG_FILE
は認証構成ファイルの名前です。例:kubectl-anthos-config.yaml
。内部ツールを使用して認証構成ファイルを各ユーザーのマシンに push します。たとえば、ツールを使用する場合は、デフォルトのファイル名
kubectl-anthos-config.yaml
を使用して、各ユーザーのマシンのデフォルトの場所にファイルを push できます。Linux
$HOME/.config/google/anthos/kubectl-anthos-config.yaml
macOS
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
Windows
%APPDATA%\google\anthos\kubectl-anthos-config.yaml
カスタム構成
前のセクションで説明したとおり、gcloud CLI は認証構成ファイルがデフォルトの場所とファイル名 kubectl-anthos-config.yaml
で保存されることを想定しています。ただし、認証構成ファイルの名前を変更し、別の場所に保存することもできます。ファイルの名前と場所がデフォルトと異なる場合は、クラスタでの認証時に実行する各コマンドに --login-config
フラグを追加する必要があります。この追加コマンドフラグが、カスタムパスとファイル名を渡します。コマンドフラグの詳細については、gcloud CLI を使用した認証をご覧ください。
gcloud CLI のインストール
このセクションは、クラスタ管理者と開発者の両方を対象としています。
クラスタで認証する必要がある各デベロッパーまたはユーザーは、自身のマシンに Google Cloud CLI をインストールする必要があります。Anthos 認証コマンドは、anthos-auth
コンポーネントとして gcloud CLI に統合されました。
「Anthos Plugin for Kubectl」の旧バージョンを使用している場合は、gcloud CLI と
anthos-auth
コンポーネントをインストールする前に、旧バージョンのプラグインをアンインストールする必要があります。既存のバージョンの gcloud CLI を使用している場合は、最新バージョンと
anthos-auth
コンポーネントをインストールします。
古いプラグインの削除
gcloud CLI の anthos-auth
コンポーネントを使用する前に、古いプラグインをアンインストールする必要があります。次のコマンドを実行して、過去の kubectl
ベースのプラグインがマシンに存在するかどうかを確認できます。
kubectl anthos version
コマンドが
Error: unknown command "anthos" for "kubectl"
で応答した場合、プラグインは存在しません。次のセクションにスキップできます。1.0beta
バージョンのプラグインが見つかった場合は、プラグインのバイナリを特定して削除する必要があります。次のコマンドを実行して場所を一覧表示し、その場所を使用してマシンからバイナリを削除します。kubectl plugin list
gcloud CLI のインストールと gcloud CLI
gcloud CLI をインストールするには、まず gcloud CLI をインストールする必要があります。
gcloud CLI をインストールしますが、
gcloud init
コマンドは省略します。次のコマンドを実行して、
anthos-auth
コンポーネントをインストールします。gcloud components update gcloud components install anthos-auth
次のいずれかのコマンドを実行して gcloud CLI が正常にインストールされたことを確認します。
gcloud anthos auth gcloud anthos auth login
結果: 各コマンドは、必要な引数と使用可能なオプションの詳細を返します。
認証構成ファイルの取得
このセクションは開発者を対象としています。
認証構成ファイルは、管理者が作成して提供します。詳しくは、認証構成ファイルの配布をご覧ください。
デフォルトでは、gcloud CLI は、認証構成ファイルに既定のファイル名と保存場所を使用します。ファイルがマニュアルで提供され、マシンに保存する必要がある場合は、デフォルト値を使用して gcloud
認証コマンドを簡素化します。
認証構成ファイルをデフォルトの場所にコピーするには、次のコマンドを使用します。
Linux
mkdir -p $HOME/.config/google/anthos/ cp AUTH_CONFIG_FILE $HOME/.config/google/anthos/kubectl-anthos-config.yaml
ここで、AUTH_CONFIG_FILE
は認証構成ファイルの名前です。例: kubectl-anthos-config.yaml
。
macOS
mkdir -p $HOME/Library/Preferences/google/anthos/ cp AUTH_CONFIG_FILE $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
ここで、AUTH_CONFIG_FILE
は認証構成ファイルの名前です。例: kubectl-anthos-config.yaml
。
Windows
md "%APPDATA%\google\anthos" copy AUTH_CONFIG_FILE "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"
ここで、AUTH_CONFIG_FILE
は認証構成ファイルの名前です。例: kubectl-anthos-config.yaml
。
別のファイル名や場所を使用する場合は、任意で各認証リクエストに --login-config
フラグを含めることができます。gcloud anthos auth login
コマンドの使用方法の詳細については、次のセクションをご覧ください。
ユーザー クラスタによる認証
このセクションは開発者を対象としています。
gcloud CLI がマシンにインストールされ、管理者によって認証構成ファイルが提供されました。これで、gcloud CLI または Google Cloud コンソールを使用してクラスタを認証できます。
gcloud CLI による認証
gcloud
コマンドを実行してクラスタで認証します。
gcloud anthos auth login
コマンドを実行して認証フローを開始します。gcloud anthos auth login \ --cluster CLUSTER_NAME \ --user USER_NAME \ --login-config AUTH_CONFIG_FILE_PATH \ --login-config-cert CA_CERT_PEM_FILE \ --kubeconfig USER_CLUSTER_KUBECONFIG
ここで
CLUSTER_NAME
(省略可)には、ユーザー クラスタの名前を指定します。このフラグを省略すると、認証構成ファイルで指定されたユーザー クラスタから選択するよう求められます。USER_NAME
(省略可)には、kubeconfig
ファイルに格納されている認証情報のユーザー名を指定します。デフォルト値は
です。CLUSTER_NAME
-anthos-default-userAUTH_CONFIG_FILE_PATH
(省略可)には、認証構成ファイルが保存またはホストされるカスタムパスまたは URL を指定します。ファイルがデフォルトの場所にある場合、このパラメータは省略できます。例:--login-config /path/to/custom/authentication-config.yaml
CA_CERT_PEM_FILE
(省略可)には、CA からの PEM 証明書ファイルのパスを指定します。認証構成ファイルが安全にホストされている場合は、HTTPS 接続を使用してファイルにアクセスできます。例:--login-config-cert my-cert.pem
USER_CLUSTER_KUBECONFIG
(省略可)には、ユーザー クラスタのkubeconfig
ファイルへのカスタムパスを指定します。OpenID プロバイダから返される OIDC ID トークンは、kubeconfig
ファイルに格納されます。このフラグは、
kubeconfig
ファイルがデフォルト以外の場所にある場合に使用します。このフラグを省略すると、デフォルトの場所に新しいkubeconfig
ファイルが作成されます。例:--kubeconfig /path/to/custom.kubeconfig
例:
特定のクラスタに対して認証します。
gcloud anthos auth login --cluster my-production-cluster
プロンプトを使用して、認証するクラスタを選択します。
gcloud anthos auth login
結果:
Please use the --cluster flag to specify a cluster from the list below: Source: $HOME/.config/google/anthos/kubectl-anthos-config.yaml 1. Cluster: test-cluster ServerIP: https://192.168.0.1:6443 2. Cluster: test-cluster-2 ServerIP: https://192.168.0.2:6443 3. Cluster: my-production-cluster ServerIP: https://192.168.0.3:6443
ホストされている認証構成ファイルを使用します。
gcloud anthos auth login \ --cluster my-production-cluster \ --login-config HTTPS://my-secure-server/kubectl-anthos-config.yaml \ --login-config-cert my-cert.pem
開いたブラウザベースの同意画面で認証情報を入力します。
kubectl
コマンドのいずれかを実行して、クラスタに関する詳細情報を取得し、認証が成功したことを確認します。次に例を示します。kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG
結果: ユーザー クラスタ上の Kubernetes API サーバーでの認証のために kubectl
コマンドで使用される ID トークンが、kubeconfig
ファイルに追加されました。
SSH を使用したリモートマシンからの認証
リモートマシンに SSH 接続し、リモートマシンからユーザー クラスタに対して認証を行うとします。これを実行するには、認証構成ファイルがリモートマシン上にあり、ローカルマシンから Open ID プロバイダにアクセスできる必要があります。
ローカルマシンで、次のコマンドを実行します。
ssh USER_NAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT
ここで
USER_NAME
とREMOTE_MACHINE
は、SSH でのログインに使用される標準の値です。LOCAL_PORT
は、リモートマシンへのアクセスに使用するローカルマシン上の任意のオープンポートです。REMOTE_PORT
は、OIDC リダイレクト URL 用に構成したポートです。これは、認証構成ファイルのkubectlRedirectURI
フィールドで確認できます。
SSH シェルで次のコマンドを実行して、認証を開始します。
gcloud anthos auth login --login-config AUTH_CONFIG_FILE
ここで、AUTH_CONFIG_FILE
はリモートマシン上の認証構成ファイルのパスです。
ローカルマシンのブラウザで、http://localhost:LOCAL_PORT
/login にアクセスして OIDC ログインフローを完了します。
これで、リモートマシンの kubeconfig ファイルに、ユーザー クラスタにアクセスするために必要なトークンが用意されます。
SSH シェルで、ユーザー クラスタにアクセスできることを確認します。
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes
Google Cloud コンソールによる認証
Google Cloud コンソール の [Kubernetes クラスタ] ページで認証フローを開始します。
-
Google Cloud コンソールを開きます。
-
一覧で Anthos clusters on VMware クラスタを見つけて、[ログイン] をクリックします。
-
[クラスタ用に構成された ID プロバイダで認証] を選択し、[ログイン] をクリックします。
ID プロバイダにリダイレクトされます。ここで、ログイン、または Google Cloud コンソールがアカウントにアクセスすることへの同意が必要となる場合があります。その後、Google Cloud コンソールの [Kubernetes クラスタ] ページにリダイレクトされます。
OIDC 構成のトラブルシューティング
OIDC の問題を解決するには、次の動作とエラーを確認してください。
- 無効な構成
- Google Cloud コンソールでクラスタから OIDC 構成を読み取れない場合、[ログイン] ボタンは無効になります。
- 無効なプロバイダ構成
- ID プロバイダの構成が無効な場合は、[ログイン] をクリックした後に、ID プロバイダからのエラー画面が表示されます。プロバイダ固有の手順に従って、プロバイダまたはクラスタを正しく構成します。
- 無効な権限
- 認証フローを完了してもクラスタの詳細が表示されない場合は、OIDC で使用したアカウントに適切な RBAC 権限が付与されていることを確認してください。これは、Google Cloud コンソールへのアクセスに使用するアカウントとは異なる場合があるので注意してください。
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
- このエラーは、認証サーバーから同意を求められたものの、必要な認証パラメータが指定されていない場合に発生します。
prompt=consent
パラメータを Anthos clusters on VMware 構成ファイルのoidc: extraparams
フィールドに指定し、--extra-params prompt=consent
フラグを使用してクライアント認証ファイルを再生成します。
次のステップ
- スコープとクレームについて詳細を確認する。