Active Directory フェデレーション サービス(AD FS)で OpenID Connect(OIDC)を使用するように Anthos clusters on VMware(GKE On-Prem)を構成する方法について説明します。このページでは、OpenID プロバイダとして AD FS サーバーを構成し、ユーザー データベースとして Active Directory を使用する一般的なプロセスを説明します。
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 のコンセプトを理解していることを前提としています。
このセクションの手順を完了するには、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 サーバーと Active Directory ユーザー データベースを構成します。
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
: 前の手順で取得したクライアント IDSERVER_ROLE_IDENTIFIER
: 前に入力したクレーム ID(推奨の ID はtoken-groups-claim
)
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: "https://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
オブジェクトのフィールドを示します。
フィールド | 必須 | 説明 | 形式 |
---|---|---|---|
name | ○ | 作成する OIDC 構成の名前。 | 文字列 |
certificateAuthorityData | × |
例: |
文字列 |
clientID | ○ | OpenID プロバイダへの認証リクエストを行うクライアント アプリケーションの ID。 | 文字列 |
clientSecret | × | OIDC クライアント アプリケーションと OIDC プロバイダ間の共有シークレット。 | 文字列 |
extraParams | × |
OpenID プロバイダに送信する追加の Key-Value パラメータ。グループを承認する場合は、 Microsoft Azure と Okta の認証で認証サーバーが同意を求めるプロンプトを表示する場合は、 |
カンマ区切りのリスト |
groupsClaim | × | プロバイダがセキュリティ グループを返すために使用する JWT クレーム。 | 文字列 |
groupPrefix | × | 既存の名前と競合しないように、グループ クレームの先頭に付加される接頭辞。たとえば、foobar という名前の 2 つのグループがある場合、接頭辞 gid- を追加します。結果のグループは gid-foobar です。 |
文字列 |
issuerURI | ○ | 認可リクエストが OpenID に送信される URL(https://example.com/adfs など)。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。URI には HTTPS を使用する必要があります。 |
URL 文字列 |
cloudConsoleRedirectURI | ○ | Google Cloud console が認証に使用するリダイレクト URL。この値は https://console.cloud.google.com/kubernetes/oidc にする必要があります。 |
URL 文字列 |
kubectlRedirectURI | ○ | kubectl が認証に使用するリダイレクト URL。 |
URL 文字列 |
scopes | ○ | OpenID プロバイダに送信する追加のスコープ。Microsoft Azure と Okta には offline_access スコープが必要です。 |
カンマ区切りのリスト |
userClaim | ○ | ユーザー名として使用する JWT クレーム。OpenID プロバイダによっては、email や name などの他のクレームを選択できます。ただし、名前が競合しないように、email 以外のクレームには発行者の URL が先頭に付加されます。 | 文字列 |
userPrefix | × | 既存の名前と競合しないように、ユーザー名のクレームの先頭に付加される接頭辞。このフィールドを指定せず、userClaim が email 以外の値の場合、接頭辞はデフォルトの issuerurl# になります。値 - を使用すると、すべての接頭辞を無効にできます。 |
文字列 |
proxy | × | auth メソッドに使用するプロキシ サーバー(該当する場合)。例: http://user:password@10.10.10.10:8888 |
文字列 |
例: ユーザーとグループの承認
多くのプロバイダは、ユーザー識別プロパティ(メールやユーザー 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
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-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
フラグを使用してクライアント認証ファイルを再生成します。
次のステップ
スコープとクレームについて詳細を確認する。
ID トークンのカスタム クレームについて確認する。