テクノロジー · 実用ガイド
kubectl の x509「unknown authority」—変更前に信頼経路を証明する
資格情報の再発行や TLS 検証の無効化前に、実際の kubeconfig、接続先、CA、プロキシ経路、提示チェーンを特定します。
kubectl の x509 エラーだけでは、どの設定、接続先、証明書チェーンが失敗したか分かりません。まず現在のプロセスが実際に使った値を確定します。
このガイドは、古いまたは統合済みの kubeconfig、意図しないプロキシ、API サーバー証明書の変更、ホスト名の不一致を信頼変更前に分離します。
クライアント、エラー、実行条件を固定する
完全なエラー、コマンド、時刻、クライアント版、シェル環境を保存し、HOME、KUBECONFIG と明示フラグを記録します。資格情報は共有しません。
最初から ~/.kube を削除したり、すべての CA を置換したりしません。失敗した TLS 経路は分かっても、使用ファイルや接続先は未確定です。
実効 kubeconfig と現在のコンテキストを証明する
current-context と config view --minify を確認します。複数ファイルは統合され、先にマップキーを設定した値が優先されます。
--raw は保護されたローカル環境だけで使い、実効出力を期待するファイルと比較して古い先頭ファイルや別 HOME を排除します。
接続先と信頼アンカーを変更せずに取り出す
server URL、tls-server-name、proxy-url、CA パス、CA data の有無を記録します。埋め込みデータは CA ファイルより優先されます。
埋め込み CA は権限制限した一時ファイルへだけ復号し、サブジェクト、発行者、有効期間、指紋を記録します。
同じ経路で提示された証明書を調べる
失敗時と同じネットワーク、VPN、コンテナから確認し、OpenSSL の -connect、-servername、-verify_return_error を使います。
proxy-url と HTTPS_PROXY、HTTP_PROXY、NO_PROXY を確認し、リーフの SAN、発行チェーン、指紋を期待する接続先と比較します。
修復前に不一致を分類する
古い管理設定、誤ったコンテキスト、CA data の上書き、中間証明書不足、プロキシ証明書、SNI 不一致を分けます。
意図しない接続先のリーフをそのまま信頼せず、信頼アンカーは所有者や認証済み制御経路から得ます。
限定した信頼契約だけを修復する
管理クラスタは公式手順で資格情報を更新して新旧項目を比較し、自主管理では検証済み発行 CA を対象項目へ設定します。
不要なプロキシを修正し、必要な場合は組織の認証済み手順で CA を取得します。検証無効化は使いません。
元の条件で検証しロールバック証拠を残す
同じ kubeconfig、コンテキスト、ネットワーク経路、元のコマンドで再試行し、端点と発行者が目的クラスタと一致することを確認します。
変更前後のハッシュ、CA 指紋、端点、プロキシ判断、更新コマンド、ロールバックファイルを保存し、一時 CA を安全に削除します。
