ベアメタル版 Anthos クラスタを構成して、クラスタに対する認証を行う OpenID Connect(OIDC)を構成する方法について説明します。このトピックでは、OpenID プロバイダを構成する方法の理解に役立つ一般的な手順を説明します。
ベアメタル版 Anthos クラスタ認証フローの概要については、認証をご覧ください。他の OpenID プロバイダを使用して OIDC を構成する方法については、次のトピックをご覧ください。
概要
ベアメタル版 Anthos クラスタは、クラスタの Kubernetes API サーバーとやり取りするための認証メカニズムの OIDC をサポートします。OIDC を使用すると、組織内のユーザー アカウントの作成、有効化、無効化の標準的な手順を使用して、Kubernetes クラスタへのアクセスを管理できます。
ユーザーがアカウントの承認を得る方法は 2 つあります。
Google Cloud CLI を使用して OIDC フローを開始し、ブラウザベースの同意ページからユーザー認可を得ます。
Google Cloud Console を使用して OIDC 認証フローを開始します。
準備
このトピックは、次の認証と OpenID のコンセプトを理解していることを前提としています。
ヘッドレス システムはサポートされていません。ブラウザベースの認証フローが使用されて、プロンプトで同意が求められ、ユーザー アカウントを承認します。
Google Cloud Console で認証するには、OIDC 認証用に構成する各クラスタを Google Cloud に登録する必要があります。
ペルソナ
このトピックでは、次の 3 つのペルソナについて説明します。
組織管理者: OpenID プロバイダを選択し、クライアント アプリケーションをプロバイダに登録します。
クラスタ管理者: 1 つ以上のクラスタを作成し、クラスタを使用する開発者用の認証構成ファイルを作成します。
開発者: 1 つ以上のクラスタでワークロードを実行し、OIDC を使用して認証します。
OpenID プロバイダの選択
このセクションは、組織管理者を対象としています。
任意の OpenID プロバイダを使用できます。認定プロバイダのリストについては、OpenID 認定資格をご覧ください。
以下の OpenID プロバイダについては、次のトピックに記載された特定の構成手順をご覧ください。
リダイレクト URL の作成
このセクションは、組織管理者を対象としています。
OpenID プロバイダが ID トークンを返すために使用できる gcloud CLI と Google Cloud コンソールの両方のリダイレクト URL を作成する必要があります。
gcloud CLI のリダイレクト URL
Google Cloud CLI は各デベロッパーのローカルマシンにインストールされ、gcloud CLI を含んでいます。1024 より大きいポート番号を指定して、リダイレクト URL に使用できます。
http://localhost:[PORT]/callback
ここで、[PORT] はポート番号です。
OpenID プロバイダを構成するときに、リダイレクト URL の 1 つとして http://localhost:[PORT]/callback
を指定します。この方法はプロバイダによって異なります。
Google Cloud コンソールのリダイレクト URL
Google Cloud コンソールのリダイレクト URL は次のとおりです。
https://console.cloud.google.com/kubernetes/oidc
OIDC プロバイダを構成するときに、リダイレクト URL の 1 つとして https://console.cloud.google.com/kubernetes/oidc
を指定します。この方法はプロバイダによって異なります。
OpenID プロバイダへのクライアント アプリケーションの登録
このセクションは、組織管理者を対象としています。
開発者が OpenID プロバイダで gcloud CLI または Google Cloud コンソールを使用するには、それら 2 つのクライアントを OpenID プロバイダに登録する必要があります。登録手順は以下のとおりです。
プロバイダの発行者 URI を確認します。gcloud CLI または Google Cloud コンソールは、ここに認証リクエストを送信します。
プロバイダに gcloud CLI 用のリダイレクト URL を提供します。
プロバイダに Google Cloud コンソール用のリダイレクト URL を提供します。この URL は https://console.cloud.google.com/kubernetes/oidc です。
単一のクライアント ID を設定します。これは、gcloud CLI と Google Cloud コンソールの両方の識別にプロバイダが使用する ID です。
単一のクライアント シークレットを設定します。gcloud CLI と Google Cloud コンソールはどちらも、このシークレットを使用して OpenID プロバイダに対する認証を行います。
gcloud CLI または Google Cloud コンソールを使用してユーザーのセキュリティ グループをリクエストできる、カスタム スコープを設定します。
プロバイダがユーザーのセキュリティ グループを返すために使用するカスタム クレーム名を設定します。
これらの手順は、OpenID プロバイダによって異なります。
クラスタでの 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 enableAccessToken: ENABLE_ACCESS_TOKEN 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
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 または Okta による認証の場合は、
offline_access
を渡します。
- Microsoft Azure または Okta による認証の場合は、
extraParams
: 省略可。OpenID プロバイダにカンマ区切りのリストとして送信する追加の Key-Value パラメータ。- 認証パラメータのリストについては、認証 URI パラメータをご覧ください。
- グループを承認する場合は、
resource=token-groups-claim
を渡します。 - 認可サーバーが同意を求めるプロンプトを表示する場合は、
prompt=consent
を渡します。
enableAccessToken
: 省略可。true
の場合、Anthos Identity Service は、ユーザーがコマンドラインからログインしたときに、ID プロバイダの userinfo エンドポイントを使用してグループ情報を取得できます。グループ クレームを提供するプロバイダ(Okta など)がある場合は、このエンドポイントからセキュリティ グループを使用して認可を行えます。設定されていない場合は、false
とみなされます。proxy
: 省略可。必要に応じて、クラスタが OIDC プロバイダに接続するのに使用するプロキシ サーバーを指定できます。例:http://user:password@10.10.10.10:8888
。空白のままにすると、デフォルトではプロキシは指定されません。deployCloudConsoleProxy
: 省略可。ユーザー認証用のオンプレミス OIDC プロバイダへの Google Cloud Console でのアクセスを許可するために、クラスタにリバース プロキシをデプロイするかどうかを指定します。ID プロバイダが公共のインターネット経由でアクセスできず、Google Cloud Console を使用して認証する場合、このフィールドはtrue
に設定する必要があります。空白のままにすると、このフィールドはデフォルトでfalse
になります。certificateAuthorityData
: 省略可。Base64 でエンコードされた OIDC プロバイダの PEM エンコード認証局証明書。文字列を作成するには、ヘッダーを含めた証明書を Base64 でエンコードします。結果の文字列は、certificateAuthorityData に 1 行で含めます。例:certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==
。 この値は必須ではない場合があります。たとえば、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
仕様を次のように指定します。
issuerURL: '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
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 コンソールを開きます。
-
一覧からベアメタル版 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
フラグを使用してクライアント認証ファイルを再生成します。
次のステップ
- スコープとクレームについて詳細を確認する。