GKE On-Prem の Active Directory フェデレーション サービス(AD FS)を使用して、OpenID Connect(OIDC)を構成する方法について説明します。
このトピックでは、Active Directory フェデレーション サービス サーバーが OpenID プロバイダとして構成され、Active Directory がユーザー データベースとして使用されます。
GKE On-Prem 認証フローの概要については、認証をご覧ください。他の OpenID プロバイダを使用して OIDC を構成する方法については、次のトピックをご覧ください。
概要
GKE On-Prem は、ユーザー クラスタの Kubernetes API サーバーとやり取りする認証メカニズムの 1 つとして OIDC をサポートしています。OIDC を使用すると、組織内のユーザー アカウントの作成、有効化、無効化の標準的な手順を使用して、Kubernetes クラスタへのアクセスを管理できます。
ユーザーがアカウントの承認を得る方法は 2 つあります。
- Google Cloud CLI を使用して OIDC フローを開始し、ブラウザベースの同意ページからユーザー認可を得ます。
Google Cloud Console を使用して OIDC 認証フローを開始します。
準備
このトピックは、次の認証と OpenID のコンセプトを理解していることを前提としています。
このトピックの手順を完了するには、既存の AD FS サーバーと Active Directory ユーザー データベースが必要です。
OIDC は AD FS バージョン 2016 以降でのみサポートされます。
AD FS の次の動作に注意してください。
バージョン 5.0 より前の AD FS では、Active Directory データベースの
Token-Groups Qualified Names
LDAP 属性がgroups
クレームにマッピングされます。5.0 以降では、この属性はToken-Groups Qualified by Domain name
です。AD FS サーバーは、ユーザー ID、発行者 ID、
openid
クレーム、groups
クレームを含むトークンを返します。groups
(5.0 ではGroup
)クレームは、ユーザーが属するセキュリティ グループのリストを示します。
ヘッドレス システムはサポートされていません。ブラウザベースの認証フローが使用されて、プロンプトで同意が求められ、ユーザー アカウントを承認します。
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] はポート番号です。
AD FS サーバーを構成するときに、リダイレクト URL の 1 つとして http://localhost:[PORT]/callback
を指定します。
Google Cloud コンソールのリダイレクト URL
Google Cloud コンソールのリダイレクト URL は次のとおりです。
https://console.cloud.google.com/kubernetes/oidc
AD FS サーバーを構成するときに、リダイレクト URL の 1 つとして https://console.cloud.google.com/kubernetes/oidc
を指定します。
AD FS の構成
このセクションは、組織管理者を対象としています。
一連の AD FS 管理ウィザードを使用して、AD FS サーバーと AD ユーザー データベースを構成します。
AD FS 管理ペインを開きます。
[Application Groups] > [Actions] > [Add an Application Group] の順に選択します。
[Server Application] を選択します。名前と説明を入力します。[Next] をクリックします。
リダイレクト URL を 2 つ入力します。クライアント ID が付与されます。これにより、AD FS サーバーは gcloud CLI と Google Cloud コンソールを識別します。後で使用するために、クライアント ID を保存します。
[Generate a shared secret] を選択します。gcloud CLI と Google Cloud コンソールは、この Secret を使用して AD FS サーバーに対する認証を行います。後で使用するために Secret を保存します。
セキュリティ グループの構成(省略可)
このセクションは、組織管理者を対象としています。
AD FS Management で、[Relying party trusts] > [Add a new relying party trust] の順に選択します。
[Claims aware] を選択し、[Start] をクリックします。
[Enter data about relying party manually] を選択します。
表示名を入力します。
次の 2 つの手順はスキップします。
[Relying party trust identifier] を入力します。例:
token-groups-claim
。Access control policy には、[Permit everyone] を選択します。つまり、すべてのユーザーが、セキュリティ グループ情報を gcloud CLI および Google Cloud コンソールと共有します。
[完了] をクリックします。
LDAP 属性のクレーム名へのマッピング
このセクションは、組織管理者を対象としています。
AD FS Management で、[Relying party trusts] > [Edit claim issuance policy] の順に選択します。
[Send LDAP Attributes as Claims] をオンにしてから [Next] をクリックします。
[Claim rule name] に「
groups
」と入力します。[Attribute store] で [Active Directory] を選択します。
テーブルの [LDAP Attribute] で、以下を選択します。
- AD FS バージョン 5.0 以降: Token-Groups Qualified by Domain name
- バージョン 5.0 より前の AD FS: Token Groups - Qualified Names
[Outgoing Claim Type] には、以下を選択します。
- AD FS バージョン 5.0 以降: Group
- バージョン 5.0 より前の AD FS: groups
[Finish] をクリックし、[Apply] をクリックします。
AD FS を利用した gcloud CLI と Google Cloud コンソールの登録
このセクションは、組織管理者を対象としています。
管理者モードで PowerShell ウィンドウを開き、次のコマンドを入力します。
Grant-AdfsApplicationPermission ` -ClientRoleIdentifier "[CLIENT_ID]" ` -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] ` -ScopeName "allatclaims", "openid"
ここで
[CLIENT_ID] は、前の手順で取得したクライアント ID です。
[SERVER_ROLE_IDENTIFIER] は、前に入力したクレーム ID です。提案された ID は
token-groups-claim
でした。
GKE On-Prem 構成ファイルに oidc
仕様を入力する
このセクションは、クラスタ管理者を対象としています。
ユーザー クラスタを作成する前に、gkectl create-config cluster
を使用して GKE On-Prem 構成ファイルを生成します。構成には次の oidc
仕様が含まれます。プロバイダに固有の値を oidc
に入力する必要があります。
oidc: issuerURL: kubectlRedirectURL: clientID: clientSecret: username: usernamePrefix: group: groupPrefix: scopes: extraParams: deployCloudConsoleProxy: caPath:
issuerURL
: 必須。OpenID プロバイダの URL(例:https://example.com/adfs
)。クライアント アプリケーション(gcloud CLI や Google Cloud コンソールなどの)で、この URL に認証リクエストを送信します。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。HTTPS を使用する必要があります。kubectlRedirectURL:
必須。gcloud CLI 用に以前に構成したリダイレクト URL。clientID
: 必須。OpenID プロバイダへの認証リクエストを行うクライアント アプリケーションの ID。gcloud
CLI と Google Cloud コンソールの両方でこの ID が使用されます。clientSecret
: 省略可。クライアント アプリケーション用の Secret。gcloud CLI と Google Cloud コンソールの両方でこのシークレットが使用されます。username
: 省略可。ユーザー名として使用する JWT クレーム。デフォルトはsub
で、これはエンドユーザーの一意の識別子である必要があります。OpenID プロバイダによっては、email
やname
などの他のクレームを選択できます。ただし、他のプラグインとの競合を避けるため、email
以外のクレームには発行者の URL が先頭に付加されます。usernamePrefix
: 省略可。既存の名前と競合しないように、ユーザー名のクレームの先頭に付加される接頭辞。このフィールドを指定せず、username
がemail
以外の値の場合、接頭辞はデフォルトのissuerurl#
になります。値-
を使用すると、すべての接頭辞を無効にできます。group
: 省略可。プロバイダがセキュリティ グループを返すために使用する JWT クレーム。groupPrefix
: 省略可。既存の名前と競合しないように、グループ クレームの先頭に付加される接頭辞。たとえば、グループfoobar
と接頭辞gid-
が指定されている場合、gid-foobar
となります。デフォルトでは、この値は空で、接頭辞はありません。scopes
: 省略可。OpenID プロバイダにカンマ区切りのリストとして送信する追加のスコープ。- Microsoft Azure による認証の場合は、
offline_access
を渡します。
- Microsoft Azure による認証の場合は、
extraParams
: 省略可。OpenID プロバイダにカンマ区切りのリストとして送信する追加の Key-Value パラメータ。- 認証パラメータのリストについては、認証 URI パラメータをご覧ください。
- グループを承認する場合は、
resource=token-groups-claim
を渡します。 - 認証サーバーが同意を求めるプロンプトを表示する場合は、
prompt=consent
を渡します。これは、Microsoft Azure で認証をする場合に必要です。
deployCloudConsoleProxy
: 省略可。ユーザー認証用のオンプレミス OIDC プロバイダへの Google Cloud Console でのアクセスを許可するために、クラスタにリバース プロキシをデプロイするかどうかを指定します。値は文字列("true"
または"false"
)で指定する必要があります。ID プロバイダが公共のインターネット経由でアクセスできず、Google Cloud Console を使用して認証する場合、このフィールドは"true"
に設定する必要があります。caPath
: 省略可。ID プロバイダのウェブ証明書を発行した認証局(CA)の証明書へのパス。この値は必須ではない場合があります。たとえば、ID プロバイダの証明書がよく知られている公開 CA によって発行された場合は、ここに値を指定する必要はありません。ただし、deployCloudConsoleProxy が「true」の場合は、よく知られている公開 CA であってもこの値を指定する必要があります。
例: ユーザーとグループの承認
多くのプロバイダは、ユーザー識別プロパティ(メールやユーザー ID など)をトークンにエンコードします。ただし、これらのプロパティには認証ポリシーに関する潜在的なリスクがあります。
- ユーザー ID を使用すると、ポリシーの読み取りと監査が困難になることがあります。
- メールでは、可用性リスク(ユーザーがメインのメールを変更した場合)とセキュリティ リスク(メールを再割り当てできる場合)の両方が発生する可能性があります。
そのため、グループ ポリシーを使用することをおすすめします。グループ ID は永続的で監査が容易なためです。
プロバイダが、次のフィールドを含む ID トークンを作成したとします。
{ 'iss': 'https://server.example.com' 'sub': 'u98523-4509823' 'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp'] ... }
このトークン形式では、構成ファイルの oidc
仕様を次のように指定します。
issueruri: 'https://server.example.com' username: 'sub' usernameprefix: 'uid-' group: 'groupList' groupprefix: 'gid-' extraparams: 'resource=token-groups-claim' ...
ユーザー クラスタを作成すると、Kubernetes のロールベースのアクセス制御(RBAC)を使用して、認証済みユーザーに特権アクセスを付与できます。たとえば、クラスタの Secret への読み取り専用アクセス権を付与する ClusterRole を作成し、認証されたグループにロールをバインドする ClusterRoleBinding リソースを作成できます。
ClusterRole
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-reader rules: - apiGroups: [""] # The resource type for which access is granted resources: ["secrets"] # The permissions granted by the ClusterRole verbs: ["get", "watch", "list"]
ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-secrets-admins subjects: # Allows anyone in the "us-east1-cluster-admins" group to # read Secrets in any namespace within this cluster. - kind: Group name: gid-us-east1-cluster-admins # Name is case sensitive apiGroup: rbac.authorization.k8s.io # Allows this specific user to read Secrets in any # namespace within this cluster - kind: User name: uid-u98523-4509823 apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io
Kubernetes API サーバーはエスケープ文字としてバックスラッシュを使用します。したがって、ユーザーまたはグループの名前に二重バックスラッシュ(\\
)が含まれている場合、フィールド値の解析時に、API サーバーはこれを単一の \
として読み込みます。API サーバーがテキスト フィールド内の \\
を正しく解釈できるようにするには、これを \\\\
に置き換える必要があります。たとえば、Kubernetes API サーバーは
"unique_name": "EXAMPLE\\\\cluster-developer"
を
"unique_name": "EXAMPLE\\cluster-developer"
として解析します。
認証構成ファイルの作成と配布
このセクションは、クラスタ管理者を対象としています。
ユーザー クラスタを作成した後、そのクラスタの認証構成ファイルを作成します。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-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
[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 コンソールを開きます。
-
リストで GKE On-Prem クラスタを見つけて、[ログイン] をクリックします。
-
[クラスタ用に構成された 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
パラメータを GKE On-Prem 構成ファイルのoidc: extraparams
フィールドに指定し、--extra-params prompt=consent
フラグを使用してクライアント認証ファイルを再生成します。
次のステップ
スコープとクレームについて詳細を確認する。
ID トークンのカスタム クレームについて確認する。