バージョン 1.8このバージョンは、Anthos バージョン サポート ポリシーに記載されているようにサポートされており、Anthos clusters on VMware(GKE On-Prem)に影響を与えるセキュリティの脆弱性、露出、問題に関する最新のパッチとアップデートが提供されます。詳細については、リリースノートをご覧ください。これは最新バージョンではありません。

OIDC と AD FS による認証

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 つあります。

  • gcloud コマンドライン ツールを使用して 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 つ以上のクラスタでワークロードを実行し、OIDC を使用して認証します。

リダイレクト URL の作成

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

OpenID プロバイダが ID トークンを返すために使用できる gcloud ツールと Cloud Console の両方にリダイレクト URL を作成する必要があります。

gcloud ツールのリダイレクト URL

Cloud SDK は各デベロッパーのローカルマシンにインストールされます。これには gcloud ツールが含まれています。1024 より大きいポート番号を指定して、リダイレクト URL に使用できます。

http://localhost:PORT/callback

PORT はポート番号に置き換えてください。

AD FS サーバーを構成するときに、リダイレクト URL の 1 つとして http://localhost:PORT/callback を指定します。

Cloud Console のリダイレクト URL

Cloud Console のリダイレクト 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 ユーザー データベースを構成します。

  1. AD FS 管理ペインを開きます。

  2. [Application Groups] > [Actions] > [Add an Application Group] の順に選択します。

  3. [Server Application] を選択します。名前と説明を入力します。[次へ] をクリックします。

  4. リダイレクト URL を 2 つ入力します。クライアント ID が付与されます。これにより、AD FS サーバーは gcloud ツールと Cloud Console を識別します。後で使用するために、クライアント ID を保存します。

  5. [Generate a shared secret] を選択します。gcloud ツールと Cloud Console は、この Secret を使用して AD FS サーバーに対する認証を行います。後で使用するために Secret を保存します。

セキュリティ グループの構成(省略可)

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

  1. AD FS Management で、[Relying party trusts] > [Add a new relying party trust] の順に選択します。

  2. [Claims aware] を選択し、[Start] をクリックします。

  3. [Enter data about relying party manually] を選択します。

  4. 表示名を入力します。

  5. 次の 2 つの手順はスキップします。

  6. [Relying party trust identifier] を入力します。例: token-groups-claim

  7. [Access control policy] で [Permit everyone] を選択します。これにより、すべてのユーザーが gcloud ツールと Cloud Console でセキュリティ グループ情報を共有します。

  8. [Finish] をクリックします。

LDAP 属性のクレーム名へのマッピング

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

  1. AD FS Management で、[Relying party trusts] > [Edit claim issuance policy] の順に選択します。

  2. [Send LDAP Attributes as Claims] をオンにしてから [Next] をクリックします。

  3. [Claim rule name] に「groups」と入力します。

  4. [Attribute store] で [Active Directory] を選択します。

  5. テーブルの [LDAP Attribute] で、以下を選択します。

    • AD FS バージョン 5.0 以降: Token-Groups Qualified by Domain name
    • バージョン 5.0 より前の AD FS: Token Groups - Qualified Names
  6. [Outgoing Claim Type] には、以下を選択します。

    • AD FS バージョン 5.0 以降: Group
    • バージョン 5.0 より前の AD FS: groups
  7. [Finish] をクリックし、[Apply] をクリックします。

AD FS への gcloud ツールと Cloud Console の登録

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

管理者モードで PowerShell ウィンドウを開き、次のコマンドを入力します。

Grant-AdfsApplicationPermission `
     -ClientRoleIdentifier "CLIENT_ID" `
     -ServerRoleIdentifier SERVER_ROLE_IDENTIFIER `
     -ScopeName "allatclaims", "openid"

次のように置き換えます。

  • CLIENT_ID: 前の手順で取得したクライアント ID

  • SERVER_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 の詳細は、Cloud Console と 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 ×

base64 でエンコードされた OIDC プロバイダの PEM エンコード証明書。文字列を作成するには、ヘッダーも含め、証明書を base64 にエンコードします。結果の文字列は certificateAuthorityData に 1 行で含めます。

例:
certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==

文字列
clientID OpenID プロバイダへの認証リクエストを行うクライアント アプリケーションの ID。 文字列
clientSecret × OIDC クライアント アプリケーションと OIDC プロバイダ間の共有シークレット。 文字列
extraParams ×

OpenID プロバイダに送信する追加の Key-Value パラメータ。グループを承認する場合は、resource=token-groups-claim を渡します。

Microsoft Azure と Okta の認証で認証サーバーが同意を求めるプロンプトを表示する場合は、extraParamsprompt=consent に設定します。Cloud Identity の場合は、extraParamsprompt=consent,access_type=offline に設定します。

カンマ区切りのリスト
groupsClaim × プロバイダがセキュリティ グループを返すために使用する JWT クレーム。 文字列
groupPrefix × 既存の名前と競合しないように、グループ クレームの先頭に付加される接頭辞。たとえば、foobar という名前の 2 つのグループがある場合、接頭辞 gid- を追加します。結果のグループは gid-foobar です。 文字列
issuerURI 認可リクエストが OpenID に送信される URL(https://example.com/adfs など)。Kubernetes API サーバーは、この URL を使用してトークン検証用の公開鍵を検出します。URI には HTTPS を使用する必要があります。 URL 文字列
cloudConsoleRedirectURI 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 × 既存の名前と競合しないように、ユーザー名のクレームの先頭に付加される接頭辞。このフィールドを指定せず、userClaimemail 以外の値の場合、接頭辞はデフォルトの 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.yamlanthos-config-3clusters.yaml の両方の認証構成ファイルを管理する必要があります。

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

  1. 各クラスタの名前が一意であることを確認します。クラスタの名前が同じ場合は、同じ認証構成ファイルに結合できません。クラスタを作成した後は、そのクラスタの名前を変更できません。

  2. 次の 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 ツールで想定されている場所を使用します。別のファイル名と場所を使用する場合は、カスタム構成をご覧ください。

次の方法で認証構成ファイルを配布することを検討してください。

  • アクセス可能な URL でファイルをホスティングする。--login-config フラグを gcloud anthos auth login コマンドに含めると、gcloud ツールはその場所から認証構成ファイルを取得します。

    安全なホストでファイルをホスティングすることを検討してください。PEM 証明書を使用して安全な HTTPS でアクセスする方法については、gcloud ツールの --login-config-cert フラグをご覧ください。

  • 各ユーザーにファイルを手動で配布する。ユーザーがファイルをダウンロードしたら、gcloud ツールで想定されているデフォルトのファイル名でデフォルトの場所にファイルを保存するようにユーザーに指示する必要があります。

    たとえば、ユーザーは次のコマンドを実行して、デフォルトのファイル名 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 ツールは、認証構成ファイルがデフォルトの場所とファイル名 kubectl-anthos-config.yaml で保存されることを想定しています。ただし、認証構成ファイルの名前を変更し、別の場所に保存することもできます。ファイルの名前と場所がデフォルトと異なる場合は、クラスタでの認証時に実行する各コマンドに --login-config フラグを追加する必要があります。この追加コマンドフラグが、カスタムパスとファイル名を渡します。コマンドフラグの詳細については、gcloud ツールによる認証をご覧ください。

gcloud ツールのインストール

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

クラスタで認証する必要があるデベロッパーやユーザーは、自分のマシンに Cloud SDK をインストールする必要があります。Anthos 認証コマンドは、anthos-auth コンポーネントとして gcloud ツールに統合されました。

古いプラグインの削除

Cloud SDK の anthos-auth コンポーネントを使用するには、古いプラグインをアンインストールする必要があります。次のコマンドを実行して、過去の kubectl ベースのプラグインがマシンに存在するかどうかを確認できます。

kubectl anthos version

  • コマンドが Error: unknown command "anthos" for "kubectl" で応答した場合、プラグインは存在しません。次のセクションにスキップできます。

  • 1.0beta バージョンのプラグインが見つかった場合は、プラグインのバイナリを特定して削除する必要があります。次のコマンドを実行して場所を一覧表示し、その場所を使用してマシンからバイナリを削除します。

    kubectl plugin list

Cloud SDK と gcloud ツールのインストール

gcloud ツールをインストールするには、まず Cloud SDK をインストールする必要があります。

  1. Cloud SDK をインストールします。ただし、gcloud init コマンドはスキップします。

  2. 次のコマンドを実行して、anthos-auth コンポーネントをインストールします。

    gcloud components update
    gcloud components install anthos-auth
  3. 次のいずれかのコマンドを実行して、gcloud ツールが正常にインストールされたことを確認します。

    gcloud anthos auth
    gcloud anthos auth login

    結果: 各コマンドは、必要な引数と使用可能なオプションの詳細を返します。

認証構成ファイルの取得

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

認証構成ファイルは、管理者が作成して提供します。詳しくは、認証構成ファイルの配布をご覧ください。

デフォルトでは、gcloud ツールは、認証構成ファイルにデフォルトのファイル名と保存場所を使用します。ファイルを手動で指定し、マシンに保存する必要がある場合は、デフォルト値を使用して 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 コマンドの使用方法の詳細については、次のセクションをご覧ください。

ユーザー クラスタによる認証

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

マシンに Cloud SDK がインストールされ、認証構成ファイルが管理者によって提供されたので、gcloud ツールまたは Cloud Console を使用してクラスタによる認証を行うことができます。

gcloud ツールによる認証

gcloud コマンドを実行してクラスタで認証します。

  1. 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
      
  2. 開いたブラウザベースの同意画面で認証情報を入力します。

  3. 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_NAMEREMOTE_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 Console による認証

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

  1. Cloud Console を開きます。

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

  2. 一覧で Anthos clusters on VMware クラスタを見つけて、[ログイン] をクリックします。

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

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

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

OIDC の問題を解決するには、次の動作とエラーを確認してください。

無効な構成
Cloud Console でクラスタから OIDC 構成を読み取れない場合、[ログイン] ボタンは無効になります。
無効なプロバイダ構成
ID プロバイダの構成が無効な場合は、[ログイン] をクリックした後に、ID プロバイダからのエラー画面が表示されます。プロバイダ固有の手順に従って、プロバイダまたはクラスタを正しく構成します。
無効な権限
認証フローを完了してもクラスタの詳細が表示されない場合は、OIDC で使用したアカウントに適切な RBAC 権限が付与されていることを確認してください。これは、Cloud Console へのアクセスに使用するアカウントとは異なる場合があるので注意してください。
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
このエラーは、認証サーバーから同意を求められたものの、必要な認証パラメータが指定されていない場合に発生します。prompt=consent パラメータを Anthos clusters on VMware 構成ファイルの oidc: extraparams フィールドに指定し、--extra-params prompt=consent フラグを使用してクライアント認証ファイルを再生成します。

次のステップ