OIDC と Google による認証

このページでは、GKE On-Prem で OpenID Connect（OIDC）を使用する方法について説明します。OIDC を使用するには、OpenID プロバイダを指定する必要があります。このトピックでは、Google を OpenID プロバイダとして使用するように GKE オンプレミスを構成する方法について説明します。

認証フローの概要については、認証をご覧ください。GKE On-Prem で OpenID プロバイダを使用する場合の一般的な情報については、OpenID Connect による認証をご覧ください。

制限事項

Google OpenID プロバイダはグループをサポートしていません。Kubernetes のロールベースのアクセス制御（RBAC）を使用して認証済みユーザーにロールを付与する場合は、グループではなく、個々のユーザーにロールを付与する必要があります。

概要

GKE On-Prem は、ユーザー クラスタの Kubernetes API サーバーとやり取りする認証メカニズムの 1 つとして OpenID Connect（OIDC）をサポートしています。OIDC を使用すると、組織内の標準的な手順に従って Kubernetes クラスタへのアクセスを管理して、従業員のアカウントの作成、有効化、無効化を行うことが可能です。

従業員が OIDC 認証フローを使用するには、次の 2 つの方法があります。

  • 従業員は、kubectl を使用して、OIDC フローを開始できます。このフローを自動化するためには、GKE On-Prem で、kubectl プラグインである Kubectl 用の Anthos プラグインを指定します。

  • 従業員は、Google Cloud Console を使用して、OIDC 認証フローを開始できます。

この演習では、kubectl と Google Cloud コンソールの両方のオプションを構成します。

準備

このトピックを読む前に、OAuth 2.0 と OpenID Connect を理解しておく必要があります。また、OpenID のスコープとクレームについても理解している必要があります。

ペルソナ

このトピックでは、次の 3 つのペルソナについて説明します。

  • 組織管理者: OpenID プロバイダを選択し、クライアント アプリケーションをプロバイダに登録します。

  • クラスタ管理者: 1 つ以上のユーザー クラスタを作成し、クラスタを使用する開発者用の認証構成ファイルを作成します。

  • デベロッパー: 1 つ以上のクラスタでワークロードを実行し、OIDC を使用して認証します。

Kubectl 用 Anthos プラグイン用のリダイレクト URL の作成

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

Google を OpenID プロバイダに構成するときに、Kubectl 用 Anthos プラグインに ID トークンを返すために使用できるリダイレクト URL を指定する必要があります。Kubectl 用の Anthos プラグインは、各デベロッパーのローカルマシンで実行され、任意のポートでリッスンします。この目的に適した 1024 より大きいポート番号を選択します。リダイレクト URL は次のようになります。

http://localhost:[PORT]/callback

ここで、[PORT] はポート番号です。

Google OpenID プロバイダを構成するときに、リダイレクト URL の 1 つとして http://localhost:[PORT]/callback を指定します。

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

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

Kubectl 用 Anthos プラグインのリダイレクト URL のほかに、Google Cloud コンソール用のリダイレクト URL も必要です。Google Cloud コンソールのリダイレクト URL は次のとおりです。

https://console.cloud.google.com/kubernetes/oidc

Google OpenID プロバイダを構成する際は、https://console.cloud.google.com/kubernetes/oidc をリダイレクト URL の 1 つとして指定します。

このセクションでは、Google の OAuth 同意画面を構成します。組織内のデベロッパーがユーザー クラスタの認証を開始すると、この同意画面が表示されます。その際、Google に ID を証明し、OAuth クライアントに識別情報を提供するトークンを作成する権限を Google に付与します。このトピックのコンテキストでは、OAuth クライアントは Kubectl 用の Anthos プラグインまたは Google Cloud コンソールです。

  1. Google Cloud コンソールの [OAuth 同意画面] ページに移動します。

    OAuth 同意画面を構成する

  2. [内部] を選択し、[作成] をクリックします。

  3. [アプリケーションの種類] で [内部] を選択します。

  4. [アプリケーション名] に任意の名前を入力します。例: GKE on-prem。

  5. [承認済みドメイン] で google.com を追加します。

  6. 必要に応じて、追加のフィールドを入力します。

  7. [保存] をクリックします。

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

このセクションでは、組織内のデベロッパーの OpenID プロバイダとして Google が機能できるように、GKE On-Prem を Google に登録します。登録の一環として、以前作成した 2 つのリダイレクト URL を指定する必要があります。

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

    [ドメインの確認] ページに移動

  2. [認証情報を作成] をクリックし、[OAuth クライアント ID] を選択します。

  3. [アプリケーションの種類] で [ウェブ アプリケーション] を選択します。

  4. [名前] に任意の名前を入力します。

  5. [承認済みのリダイレクト URI] に、2 つのリダイレクト URL を追加します。Kubectl 用の Anthos プラグインのリダイレクト URL と Google Cloud コンソールのリダイレクト URL を作成したことを思い出してください。

  6. [作成] をクリックします。

  7. クライアント ID とクライアント シークレットが表示されます。後で使用するため、保存しておきます。

GKE On-Prem 構成ファイルに oidc 仕様を入力する

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

ユーザー クラスタを作成する前に、gkectl create-config を使用して GKE On-Prem 構成ファイルを生成します。構成には次の oidc 仕様が含まれます。プロバイダに固有の値で、oidc を入力します。

oidc:
  issuerurl:
  kubectlredirecturl:
  clientid:
  clientsecret:
  username:
  usernameprefix:
  group:
  groupprefix:
  scopes:
  extraparams:
  usehttpproxy:
  capath:
  • issuerurl: "https://accounts.google.com" に設定します。Kubectl 用とGoogle Cloud コンソール用の Anthos プラグインなどのクライアント アプリケーションは、この URL に認可リクエストを送信します。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。
  • kubectlredirecturl: Kubectl 用の Anthos プラグイン用に以前に構成したリダイレクト URL。
  • clientid: OpenID プロバイダへの認証リクエストを行うクライアント アプリケーションの ID。Kubectl 用と Google Cloud コンソール用の両方の Anthos プラグインが、この ID を使用します。この ID は、Google にクライアント アプリケーションを登録したときに渡されました。
  • clientsecret: クライアント アプリケーション用の Secret。Kubectl 用と Google Cloud コンソール用の両方の Anthos プラグインが、この Secret を使用します。この ID は、Google にクライアント アプリケーションを登録したときに渡されました。
  • username: "email" に設定します。
  • usernameprefix: 省略可。既存の名前と競合しないように、ユーザー名のクレームの先頭に付加される接頭辞。このフィールドを指定せず、username が email 以外の値の場合、接頭辞はデフォルトの issuerurl# になります。値 - を使用すると、すべてのプレフィックスを無効にできます。
  • group: 空白のままにします。
  • groupprefix: 空白のままにします。
  • scopes: "email" に設定します。
  • extraparams: "prompt=consent,access_type=offline" に設定します。
  • usehttpproxy: "false" に設定します。
  • capath: 空白のままにします。

ユーザー クラスタの 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: [""]
  resources: ["secrets"]
  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

最初の認証構成ファイルの作成

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

ユーザー クラスタの作成後、クラスタの認証構成ファイルを作成します。

gkectl create-login-config --kubeconfig [USER_CLUSTER_KUBECONFIG]

ここで、[USER_CLUSTER_KUBECONFIG] はユーザー クラスタの kubeconfig ファイルのパスです。ユーザー クラスタを作成したときに、gkectl create cluster によってクラスタ用の kubeconfig ファイルが生成されています。

上記のコマンドでは、現在のディレクトリに kubectl-anthos-config.yaml という名前のファイルを作成します。

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

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

複数のクラスタの認証構成を 1 つのファイルに格納できます。次に、そのクラスタすべてにアクセスする必要のあるデベロッパーにそのファイルを 1 つずつ配布します。

既存の認証構成ファイルから始めます。次のコマンドを使用して、そのファイルを追加のクラスタの構成と結合します。

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] と同じでかまいません。

認証構成ファイルの配布

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

デベロッパーに配布する認証構成ファイルの名前は、kubectl-anthos-config.yaml にする必要があります。認証構成ファイルはさまざまな方法で配布できます。

  • 各デベロッパーに手動でファイルを提供します。

  • デベロッパーがダウンロードできるように、1 つの URL でファイルを管理します。

  • 各デベロッパーのマシンにファイルを 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

認証構成ファイルの配置

このセクションはデベロッパーを対象としています。

認証構成ファイルには、認証できるすべてのクラスタの詳細が含まれています。このファイルの内容は変更しないでください。

クラスタ管理者が認証構成ファイルを提供している場合は、適切なディレクトリにファイルを配置します。クラスタ管理がすでにマシンに構成を適用している場合は、このセクションを省略できます。

認証構成ファイルをデフォルトの場所にコピーします。

Linux

mkdir -p  $HOME/.config/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml

ここで、[AUTH_CONFIG_FILE] は認証構成ファイルの名前です。

macOS

mkdir -p  $HOME/Library/Preferences/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

ここで、[AUTH_CONFIG_FILE] は認証構成ファイルの名前です。

Windows

md "%APPDATA%\google\anthos"
copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

ここで、[AUTH_CONFIG_FILE] は認証構成ファイルの名前です。

Kubectl 用 Anthos プラグインの取得

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

Kubectl 用 Anthos プラグインは、次の管理者ワークステーションに含まれています。

Linux

/usr/bin/kubectl_anthos/v1.0beta/linux_amd64/kubectl-anthos

macOS

/usr/bin/kubectl_anthos/v1.0beta/darwin_amd64/kubectl-anthos

Windows

/usr/bin/kubectl_anthos/v1.0beta/windows_amd64/kubectl-anthos

デベロッパーにプラグインを配布するか、デベロッパーにプラグインを直接ダウンロードしてもらうことができます。

Kubectl 用 Anthos プラグインのダウンロード

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

各デベロッパーは、各自のパソコンに Kubectl 用の Anthos プラグインをインストールする必要があります。デベロッパーがプラグインを個別にダウンロードすることも、クラスタ管理者がプラグインをダウンロードしてデベロッパーに配布することもできます。

デベロッパー向けの注意事項: 使用するプラグインのバージョンをクラスタ管理者に問い合わせてください。

Kubectl 用 Anthos プラグインをダウンロードします。

Linux

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/linux_amd64/kubectl-anthos ./
chmod +x kubectl-anthos

macOS

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/darwin_amd64/kubectl-anthos ./
chmod +x kubectl-anthos

Windows

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/windows_amd64/kubectl-anthos ./
rename kubectl-anthos kubectl-anthos.exe.

Kubectl 用 Anthos プラグインのインストール

このセクションはデベロッパーを対象としています。

クラスタ管理者から Kubectl 用 Anthos プラグインが提供される場合があります。または、クラスタ管理者から、自分でプラグインをダウンロードするように指示されることもあります。

Kubectl 用 Anthos プラグインをインストールするには、実行可能ファイルを PATH 上の任意の場所に移動します。実行可能ファイルの名前は kubectl-anthos とする必要があります。詳細は、kubectl プラグインのインストールをご覧ください。

Kubectl 用の Anthos プラグインがインストールされていることを確認します。

kubectl plugin list
kubectl anthos version

利用可能クラスタの一覧表示

このセクションはデベロッパーを対象としています。

認証構成ファイルがデフォルトのパスにある場合は、次のコマンドを入力して、認証できるクラスタを一覧表示します。

kubectl anthos listclusters

認証構成ファイルがデフォルトのパスにない場合は、次のコマンドを入力して、クラスタを一覧表示します。

kubectl anthos listclusters --loginconfig [AUTH_CONFIG_FILE]

ここで、[AUTH_CONFIG_FILE] は認証構成ファイルへのパスです。

Kubectl 用 Anthos プラグインを使用した認証

このセクションはデベロッパーを対象としています。

ユーザー クラスタにログインします。

kubectl anthos login --cluster [CLUSTER_NAME] --user [USER_NAME] \
    --loginconfig [AUTH_CONFIG_FILE] --kubeconfig [USER_CLUSTER_KUBECONFIG]

ここで

  • [CLUSTER_NAME] はユーザー クラスタの名前です。この名前は、kubectl anthos listclusters コマンドで提供されるリストから選択する必要があります。

  • [USER_NAME] は、kubeconfig ファイルに保存されている認証情報のユーザー名を指定するオプションのパラメータです。デフォルト値は [CLUSTER_NAME]-anthos-default-user です。

  • [AUTH_CONFIG_FILE] は、認証構成ファイルのパスです。認証構成ファイルがデフォルトの場所にある場合は、このパラメータを省略できます。

  • [USER_CLUSTER_KUBECONFIG] はユーザー クラスタの kubeconfig ファイルのパスです。kubeconfig ファイルが存在しない場合、コマンドで認証構成ファイルから新しい kubeconfig ファイルが生成され、kubeconfig ファイルにクラスタの詳細とトークンが追加されます。

kubectl anthos login で、認証情報を入力できるブラウザを起動します。

現在指定されている kubeconfig ファイルには、kubectl でユーザー クラスタ上の Kubernetes API サーバーに認証するために使用される ID トークンが含まれています。

kubectl anthos login コマンドには、オプションの --dry-run フラグがあります。--dry-run フラグを指定すると、kubeconfig ファイルにトークンを追加する kubectl コマンドが出力されますが、実際には kubeconfig ファイルにトークンは保存されません。

kubectl コマンドを入力して、認証が成功したことを確認します。次に例を示します。

kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

Google Cloud Console での OIDC の使用

このセクションは開発者を対象としています。

  1. クラスタが OIDC 用に構成されていることを確認します。

  2. クラスタが、自動でクラスタ作成中に、または手動で Google Cloud で登録されていることを確認します。

  3. Google Cloud コンソールの [Kubernetes クラスタ] ページにアクセスします。

    [Kubernetes クラスタ] ページに移動

  4. クラスタのリストで、GKE On-Prem クラスタを見つけ、[ログイン] をクリックします。

  5. [クラスタ用に構成された ID プロバイダで認証] を選択し、[ログイン] をクリックします。

    ID プロバイダにリダイレクトされます。ここで、ログイン、または Google Cloud コンソールがアカウントにアクセスすることへの同意が必要となる場合があります。その後、Google Cloud コンソールの [Kubernetes クラスタ] ページに再度リダイレクトされます。

カスタム構成

デフォルトでは、Kubectl 用 Anthos プラグインでは、認証構成ファイルが特定の場所にあることが想定されています。認証構成ファイルをデフォルトの場所に配置しない場合は、--login-config フラグを使用して手動で認証構成ファイルのパスをプラグイン コマンドに渡すことができます。たとえば、Kubectl 用 Anthos プラグインを使用した認証をご覧ください。

GKE On-Prem における OIDC のトラブルシューティング

無効な構成

Google Cloud コンソールでクラスタから OIDC 構成を読み取れない場合、[ログイン] ボタンは無効になります。

無効なプロバイダ構成

ID プロバイダの構成が無効な場合は、[ログイン] をクリックした後に、ID プロバイダからのエラー画面が表示されます。プロバイダ固有の手順に従って、プロバイダまたはクラスタを正しく構成します。

無効な権限

認証フローを完了してもクラスタの詳細が表示されない場合は、OIDC で使用したアカウントに適切な RBAC 権限が付与されていることを確認してください。これは、Google Cloud コンソールへのアクセスに使用するアカウントとは異なる場合があるので注意してください。

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

このエラーは、認可サーバーから同意を求められたものの、必要な認証パラメータが指定されていない場合に発生します。prompt=consent パラメータを GKE On-Prem 構成ファイルの oidc: extraparams フィールドに指定し、--extra-params prompt=consent フラグを使用してクライアント認証ファイルを再生成します。

次のステップ