バージョン 1.6。このバージョンは現在サポートされていません。詳細については、バージョンのサポートポリシーをご覧ください。バージョン 1.7 にアップグレードする方法については、1.7 ドキュメントのベアメタル版 Anthos のアップグレードをご覧ください。

利用可能なサポートされているバージョン: 1.13 | 1.12 | 1.11

OIDC と Google による認証

ベアメタル版 Anthos クラスタで OpenID Connect（OIDC）を構成し、Google を OpenID プロバイダとして利用する方法について説明します。

ベアメタル版 Anthos クラスタ認証フローの概要については、認証をご覧ください。他の OpenID プロバイダを使用して OIDC を構成する方法については、次のトピックをご覧ください。

概要

ベアメタル版 Anthos クラスタは、クラスタの Kubernetes API サーバーとやり取りするための認証メカニズムの 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 同意画面] ページに移動します。

OAuth 同意画面を構成する
[内部] を選択し、[作成] をクリックします。
[アプリケーションの種類] で [内部] を選択します。
[アプリケーション名] に任意の名前を入力します。例: bare metal。
[承認済みドメイン] で google.com を追加します。
必要に応じて、追加のフィールドを入力します。
[保存] をクリックします。

クライアントアプリケーションを Google に登録する

このセクションでは、ベアメタル版 Anthos クラスタを Google に登録します。その結果、Google が組織内のデベロッパーに対する OpenID プロバイダとなります。登録の一環として、以前作成した 2 つのリダイレクト URL を指定する必要があります。

Google Cloud Console の [認証情報] ページに移動します。

[ドメインの確認] ページに移動
[認証情報を作成] をクリックし、[OAuth クライアント ID] を選択します。
[アプリケーションの種類] で [ウェブアプリケーション] を選択します。
[名前] に任意の名前を入力します。
[承認済みのリダイレクト URI] の下に、2 つのリダイレクト URL を追加します。gcloud CLI のリダイレクト URL と Google Cloud コンソールのリダイレクト URL を作成したことを思い出してください。
[作成] をクリックします。
クライアント ID とクライアントシークレットが表示されます。後で使用するため、保存しておきます。

ベアメタル版 Anthos クラスタ構成ファイルに `oidc` 仕様を入力する

このセクションは、クラスタ管理者を対象としています。

クラスタを作成する前に、bmctl create config を使用してベアメタル版 Anthos クラスタ構成ファイルを生成します。構成には次の oidc 仕様が含まれます。プロバイダ固有の値を oidc に入力する必要があります。

authentication:
  oidc:
    issuerURL:
    kubectlRedirectURL:
    clientID:
    clientSecret:
    username:
    usernamePrefix:
    group:
    groupPrefix:
    scopes:
    extraParams:
    proxy:
    deployCloudConsoleProxy:
    certificateAuthorityData:

issuerURL: "https://accounts.google.com" に設定します。クライアントアプリケーション（gcloud CLI や Google Cloud コンソールなどの）で、この URL に認証リクエストを送信します。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。
kubectlRedirectURL: 必須。gcloud CLI 用に以前に構成したリダイレクト URL。
clientID: OpenID プロバイダへの認証リクエストを行うクライアントアプリケーションの ID。gcloud CLI と Google Cloud コンソールの両方でこの ID が使用されます。この ID は、Google にクライアントアプリケーションを登録したときに渡されました。
clientSecret: クライアントアプリケーション用の Secret。gcloud CLI と Google Cloud コンソールの両方でこのシークレットが使用されます。この ID は、Google にクライアントアプリケーションを登録したときに渡されました。
username: "email" に設定します。
usernamePrefix: 省略可。既存の名前と競合しないように、ユーザー名のクレームの先頭に付加される接頭辞。このフィールドを指定せず、username が email 以外の値の場合、接頭辞はデフォルトの issuerurl# になります。値 - を使用すると、すべてのプレフィックスを無効にできます。
group: 空白のままにします。
groupPrefix: 空白のままにします。
scopes: "email" に設定します。
extraParams: "prompt=consent,access_type=offline" に設定します。
proxy: 省略可。ベアメタル版 Anthos クラスタ 1.6.1 から開始することで、該当する場合は OIDC プロバイダに接続するためのプロキシサーバーを指定できます。例: http://user:password@10.10.10.10:8888。空白のままにすると、デフォルトではプロキシは指定されません。
deployCloudConsoleProxy: false に設定します。
certificateAuthorityData: 空白のままにします。

クラスタの RBAC ポリシーを作成する

このセクションは、クラスタ管理者を対象としています。

クラスタを作成したら、Kubernetes ロールベースのアクセス制御（RBAC）を使用して、認証済みクラスタユーザーにアクセスを許可します。特定の Namespace のリソースへのアクセスを許可するには、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 [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role.yaml

ここで、[CLUSTR_KUBECONFIG] はクラスタの kubeconfig ファイルです。

ClusterRoleBinding を作成するには、マニフェストを secret-viewer-cluster-role-binding.yaml というファイルに保存し、次のコマンドを入力します。

kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role-binding.yaml

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
```
結果: 各コマンドは、必要な引数と使用可能なオプションの詳細を返します。

認証構成ファイルの作成と配布

このセクションは、クラスタ管理者を対象としています。

クラスタを作成した後、そのクラスタの認証構成ファイルを作成します。1 つの認証構成ファイルで複数のクラスタを構成できます。各認証構成ファイルを、それぞれのクラスタで認証を行うユーザーに提供する必要があります。

認証構成ファイルの作成

現在のディレクトリに認証構成ファイルを作成するには、次の gcloud コマンドを実行します。

gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG]

ここで、[CLUSTER_KUBECONFIG] はクラスタの kubeconfig ファイルのパスです。bmctl create cluster を実行してクラスタを作成したときに、kubeconfig ファイルが作成されています。

結果: 現在のディレクトリに kubectl-anthos-config.yaml という名前の認証構成ファイルが作成されます。

認証構成ファイルへの複数のクラスタの追加

複数のクラスタの認証構成の詳細を、1 つの認証構成ファイルに保存できます。

次のコマンドを使用すると、追加のクラスタ認証の詳細を既存の認証構成ファイルに結合できます。既存の認証構成ファイルがある場合、追加のユーザークラスタ認証の詳細を結合または組み合わせることができます。

追加のクラスタ認証の詳細を、既存の認証構成ファイルに結合する。
追加のクラスタ認証の詳細と組み合わせて、新しいファイルを作成する。

たとえば、組織内の複数のユーザーグループのアクセスニーズに対応するために、anthos-config-1cluster.yaml と anthos-config-3clusters.yaml の両方の認証構成ファイルを管理する必要があります。

既存の認証構成ファイルにクラスタを追加するには:

各クラスタの名前が一意であることを確認します。クラスタの名前が同じ場合は、同じ認証構成ファイルに結合できません。クラスタを作成した後は、そのクラスタの名前を変更できません。
次の gcloud コマンドを実行して、構成の詳細を結合するか、組み合わせます。
```
gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG] \
--merge-from [IN_AUTH_CONFIG_FILE] --output [OUT_AUTH_CONFIG_FILE]
```
ここで
- [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 は、認証構成ファイルに既定のファイル名と保存場所を使用します。ファイルがマニュアルで提供され、マシンに保存する必要がある場合は、デフォルト値を使用して 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 [CLUSTER_KUBECONFIG]
```
ここで
- [CLUSTER_NAME]（省略可）には、クラスタの名前を指定します。このフラグを省略すると、認証構成ファイルで指定されたクラスタから選択するよう求められます。
- [USER_NAME]（省略可）には、kubeconfig ファイルに格納されている認証情報のユーザー名を指定します。デフォルト値は [CLUSTER_NAME]-anthos-default-user です。
- [AUTH_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
- [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 [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 [CLUSTER_KUBECONFIG] get nodes

Google Cloud コンソールによる認証

Google Cloud コンソールの [Kubernetes クラスタ] ページで認証フローを開始します。

Google Cloud コンソールを開きます。

[Kubernetes クラスタ] ページに移動
一覧からベアメタル版 Anthos クラスタを見つけて、[ログイン] をクリックします。
[クラスタ用に構成された 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 クラスタ構成ファイルの oidc: extraparams フィールドに指定し、--extra-params prompt=consent フラグを使用してクライアント認証ファイルを再生成します。

次のステップ

スコープとクレームについて詳細を確認する。

OIDC と Google による認証

概要

準備

ペルソナ

リダイレクト URL を作成する

gcloud CLI のリダイレクト URL

Google Cloud コンソールのリダイレクト URL

同意画面の構成

クライアント アプリケーションを Google に登録する

ベアメタル版 Anthos クラスタ構成ファイルに oidc 仕様を入力する

クラスタの RBAC ポリシーを作成する

gcloud CLI のインストール

古いプラグインの削除

gcloud CLI のインストールと gcloud CLI

認証構成ファイルの作成と配布

認証構成ファイルの作成

認証構成ファイルへの複数のクラスタの追加

認証構成ファイルの配布

Linux

macOS

Windows

Linux

macOS

Windows

カスタム構成

認証構成ファイルの取得

Linux

macOS

Windows

クラスタによる認証

gcloud CLI による認証

SSH を使用したリモートマシンからの認証

Google Cloud コンソールによる認証

OIDC 構成のトラブルシューティング

次のステップ

クライアントアプリケーションを Google に登録する

ベアメタル版 Anthos クラスタ構成ファイルに `oidc` 仕様を入力する