ID と認可のトラブルシューティング

Version 1.9 

• Version 1.28 (latest)
• Version 1.16
• Version 1.15
• Earlier versions (unsupported)

このドキュメントでは、ID と認可に関する問題のトラブルシューティングについて説明します。

gcloud anthos auth を最新の状態に維持する

一般的な問題の多くは、gcloud anthos auth のインストール コンポーネントが最新であることを確認することで回避できます。

gcloud anthos auth コマンドには gcloud コア コンポーネントに対するロジックと、個別にパッケージ化された anthos-auth コンポーネントがあるため、検証が必要な部分は 2 つあります。

gcloud を更新します。

gcloud components update

anthos-auth を更新します。

gcloud components install anthos-auth

無効なプロバイダ構成

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

無効な権限

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

更新トークンが見つからない

認可サーバーが同意を求めるプロンプトを表示しても、必要な認証パラメータが指定されなかった場合は、次の問題が発生します。

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

この問題を解決するには、クラスタ構成ファイルで authentication.oidc.extraParams フィールドに prompt=consent を追加します。次に、クライアント認証ファイルを再生成します。

更新トークンが期限切れ

この問題は、kubeconfig ファイルの更新トークンの期限が切れたときに発生します。

Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
    certificate signed by unknown authority

この問題を解決するには、もう一度 login コマンドを実行します。

gkectl create-login-config が clientconfig を取得できない

この問題は、gkectl create-login-config に渡された kubeconfig ファイルがユーザー クラスタ用ではない場合、または ClientConfig カスタム リソースがクラスタの作成中に起動しなかった場合に発生します。

Error getting clientconfig using KUBECONFIG

この問題を解決するには、ユーザー クラスタ用に正しい kubeconfig ファイルがあることを確認してください。次に、ClientConfig オブジェクトがクラスタ内に存在するかどうかを確認します。

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG  get clientconfig default -n kube-public

クラスタ名が重複しているため gkectl create-login-config が失敗する

この問題は、宛先ファイルにすでに存在するクラスタ名を含むログイン構成データの書き込みを試行した場合に発生します。各ログイン構成ファイルには一意のクラスタ名を指定する必要があります。

error merging with file MERGE_FILE because MERGE_FILE contains a
  cluster with the same name as the one read from KUBECONFIG. Please write to
  a new output file

この問題を解決するには、--output フラグを使用して新しい宛先ファイルを指定します。

--output を指定しない場合、このログイン構成データは、現在のディレクトリの kubectl-anthos-config.yaml という名前のファイルに書き込まれます。

gcloud anthos auth login が proxyconnect tcp で失敗する

この問題は、https_proxy または HTTPS_PROXY の環境変数の構成にエラーがある場合に発生します。環境変数に https:// が指定されている場合は、SOCK5 などの他のプロトコルを使用して HTTPS 接続を処理するようにプロキシが構成されると、GoLang HTTP クライアント ライブラリが失敗する可能性があります。

表示される可能性のあるエラー メッセージ:

proxyconnect tcp: tls: first record does not look like a TLS handshake

この問題を解決するには、https:// prefix を省略するように、https_proxy 環境変数と HTTPS_PROXY 環境変数を変更します。Windows で、システム環境変数を変更します。たとえば、https_proxy 環境変数の値を https://webproxy.example.com:8000 から webproxy.example.com:8000 に変更します。

gcloud anthos auth login によって生成された kubeconfig を使用すると、クラスタへのアクセスに失敗する

この問題は、Kubernetes API サーバーでユーザーを認可できない場合に発生します。適切な RBAC が指定されていないか、RBAC が正しくない、あるいはクラスタの OIDC 構成にエラーがある場合に、この状況が発生する可能性があります。

Unauthorized

この問題を解決するには:

1. gcloud anthos auth login によって生成された kubeconfig ファイルで、id-token の値をコピーします。

   kind: Config
   …
   users:
   — name: …
     user:
       auth-provider:
         config:
           id-token: xxxxyyyy
   

2. jwt-cli をインストールし、次のコマンドを実行します。

   jwt ID_TOKEN
   

3. OIDC 構成の検証

   ユーザー クラスタ構成ファイルの authentication.oidc には group フィールドと username フィールドがあり、Kubernetes API サーバーで --oidc-group-claim フラグと --oidc-username-claim フラグを設定するために使用されます。API サーバーにトークンが渡されると、トークンを Anthos Identity サービスに転送します。これにより、抽出された group-claim と username-claim が API サーバーに返されます。API サーバーはレスポンスを使用して、対応するグループまたはユーザーに正しい権限が付与されていることを確認します。

   クラスタ構成ファイルの authentication.oidc セクションで group と user に設定されたクレームが ID トークンに存在することを確認します。

4. 適用されている RBAC を確認します。

   username-claim で指定したユーザー、または前のステップで取得した group-claim に示されたいずれかのグループに対する適切な権限を持つ RBAC があることを確認します。RBAC 内のユーザーまたはグループの名前には、ユーザー クラスタ構成ファイルで指定されている usernameprefix 接頭辞または groupprefix 接頭辞を付加する必要があります。

   usernameprefix が空白で、username が email 以外の値である場合、接頭辞はデフォルトで issuerurl# に設定されます。ユーザー名の接頭辞を無効にするには、usernameprefix を - に設定します。

   ユーザーおよびグループの接頭辞の詳細については、OIDC による認証をご覧ください。

   Kubernetes API サーバーはエスケープ文字としてバックスラッシュを使用します。したがって、ユーザーまたはグループの名前に \\ が含まれている場合、API サーバーは ID トークンを解析するときに、1 つの \ としてそれを読み取ります。このユーザーまたはグループに適用される RBAC ロール バインディングには、バックスラッシュを 1 つだけ含める必要があります。そうしないと、Unauthorized エラーが発生することがあります。

   クラスタ構成ファイル:

   oidc:
     ...
     username: "unique_name"
     usernameprefix: "-"
     group: "group"
     groupprefix: "oidc:"
   

   ID トークン:

   {
     ...
     "email": "[e-mail]",
     "unique_name": "EXAMPLE\\cluster-developer",
     "group": [
       "Domain Users",
       "EXAMPLE\\developers"
     ],
   ...
   }
   

   次の RBAC バインディングによって、このグループとユーザーに pod-reader クラスタのロールが付与されます。名前フィールドには、ダブル スラッシュではなく、単一スラッシュが使用されています。

   グループ ClusterRoleBinding:

   apiVersion:
   kind: ClusterRoleBinding
   metadata:
     name: example-binding
   subjects:
   — kind: Group
     name: "oidc:EXAMPLE\developers"
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: pod-reader
     apiGroup: rbac.authorization.k8s.io
   

   ユーザー ClusterRoleBinding:

   apiVersion:
   kind: ClusterRoleBinding
   metadata:
     name: example-binding
   subjects:
   — kind: User
     name: "EXAMPLE\cluster-developer"
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: pod-reader
     apiGroup: rbac.authorization.k8s.io
   

5. Kubernetes API サーバーのログを確認します。

   ID トークンを渡した際に、Kubernetes API サーバーで構成された OIDC プラグインが正しく起動していないと、API サーバーから Unauthorized エラーが返されます。API サーバーで OIDC プラグインに問題があったかどうかを確認するには、次のコマンドを実行します。

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG logs statefulset/kube-apiserver -n USER_CLUSTER_NAME