プロンプトとコンテキスト
プラットフォームチームは、同一のアイデンティティにKubeletのdebugやexecエンドポイントへのアクセスを付与することなく、kube-apiserverがノードメトリクスを読み取れるようにする必要があります。クラスターは粗い認可動作からKubernetes v1.36へとアップグレード中であり、監視の停止を起こさず、ノードレベルの権限拡張を行わず、監査可能な証跡を保持する必要があります。認証パス、認可属性、移行、ロールバック、および検証メトリクスについて説明してください。
面接官が評価するポイント
- RBACのみを議論するのではなく、Kubelet HTTPSエンドポイントの認証と認可を分離して捉えているか。
- 動詞（verb）、リソース、サブリソース、ノード、およびネームスペースの属性を用いて最小特権を表現できているか。
- API ServerのKubeletクライアントアイデンティティに明示的な認可ルールが必要であることを理解しているか。
- 互換性移行、fail-closedな動作、監査性、およびロールバックを設計できているか。
確認すべき明確化のための質問
- Kubelet APIを必要とする呼び出し元はどれですか：API Serverのみ、監視エージェント、それともノードに直接接続するオペレーターですか？
- どの機能が必要ですか：メトリクス、ログ、実行中コンテナの状態、コマンド実行、またはポートフォワーディングですか？
- Kubeletはクライアント証明書または他の認証方法を使用していますか？また、API Serverの認可コールバックは利用可能ですか？
- ロールアウト中に短時間の読み取り専用の性能低下は許容されますか？また、監視停止の許容時間はどのくらいですか？
30秒の回答フレームワーク
パスを3つのレイヤーに分割します：TLSまたは他の認証機能が呼び出し元のアイデンティティを確立し、Kubeletオーソライザーがリクエストを属性にマッピングし、認可サービスが判定を下します。debug、exec、およびプロキシ機能を隔離し、必要なノードエンドポイントのみに最小特権ルールを適用します。呼び出しをインベントリ化し、拒否を観測し、段階的にルールを厳格化し、メトリクスとロールバックスイッチが整った後にのみ強制拒否へと切り替えることで移行します。
ステップごとの詳細解説
1. 認証、認可、およびリクエスト属性
Kubelet HTTPSエンドポイントは、まずクライアント証明書または設定された認証機能を検証し、ユーザー名とグループを取得します。認可は、HTTPリクエストを動詞（verb）、リソース、サブリソース、ネームスペース、名前、ノードなどのKubernetes属性にマッピングします。認証の成功は認可を意味するわけではありません。すべてのエンドポイントで判定が必要です。API ServerがKubeletを呼び出す際、--kubelet-client-certificateと一致するキーによって管理されたプリンシパルが識別され、認可システム内で明示的な権限を持つ必要があります。
2. サブリソースによる最小特権の表現
メトリクス、ログ、コンテナ状態、およびデバッグ実行を別々の機能として扱います。必要な読み取り専用ノードリソースまたはサブリソースのみを付与し、ノードのスコープを制限します。単に監視を動作させるためだけに、ワイルドカードリソースや広範なnodes/proxyアクセスを付与してはなりません。コマンド実行、ポートフォワーディング、デバッグエンドポイントには、API Serverの通常のサービスアイデンティティとは紐付けない、個別の高リスクロールを割り当てます。
3. 移行と互換性
現在の監査ログおよびアクセスログから呼び出しマトリクスを構築します：アイデンティティ、パス、動詞、対象ノード、結果、呼び出し元のバージョン。きめ細かな認可を有効にした後、収集を中断することなく拒否対象となるリクエストを記録する観測フェーズを実行し、必要なルールのみを埋めて、ノードを段階的に切り替えます。KubeletFineGrainedAuthzはKubernetes v1.36でGAとなりデフォルトで有効化されていますが、ロールアウト時にはディストリビューションのデフォルト設定、API Serverのクライアント認証情報、および各監視コンポーネントのパスを検証する必要があります。
4. オブザーバビリティ、ロールバック、および多層防御
許可と拒否の両方の監査イベントを、アイデンティティ、ノード、リソース、理由とともに記録します。認可レイテンシ、拒否率、メトリクス収集の成功率、および予期しないエンドポイントアクセスを監視します。ロールアウトによって監視が停止した場合は、まずクライアント権限をロールバックするか、高リスクなエンドポイントを閉じたまま一時的に互換性ルールを復元します。ネットワーク制御によってKubeletポートへの到達性を制限し続ける必要があります。認可はTLS、ネットワーク分離、ノードアイデンティティ保護の代わりになるものではありません。
模範回答
まずKubeletエンドポイントの認証機能を確認し、次に各リクエストを標準の認可属性にマッピングします。API Serverは管理されたクライアント証明書を使用し、認可システムは最小特権のために動詞、リソース、サブリソース、ノード、ネームスペースを評価します。メトリクス収集には必要な読み取り専用機能のみが付与されます。exec、ポートフォワーディング、およびデバッグエンドポイントは個別の高リスクロールを使用し、ワイルドカード権限や広範なnodes/proxyアクセスは通常のAPI Serverアイデンティティには付与しません。
移行は4つの段階で行われます：呼び出しマトリクスのインベントリ化、収集を中断しない拒否の観測、ノードおよびコンポーネントのバッチ単位での最小ルールの追加、そしてロールバックスイッチを備えた強制拒否の適用です。KubeletFineGrainedAuthzはv1.36でGAとなりデフォルトで有効ですが、ディストリビューションの設定、API Serverの認証情報、監視のバージョンを検証します。監査ログにはアイデンティティ、ノード、リソース、結果、理由が保持され、ネットワークポリシーは認可、トランスポート、ネットワーク制御が一体となるようKubeletポートを引き続き制限します。
よくある間違い
- TLS認証を設定したことで、クライアント証明書がすべてのKubelet APIを許可すると誤認すること。
- 監視を修正するためにワイルドカードリソースや広範な
nodes/proxy権限を使用すること。 - 呼び出しマトリクスなしに拒否を強制し、アップグレード後にサイレントな収集障害を引き起こすこと。
- API Serverとオペレーターのデバッグ用に単一の高権限ロールを使い回すこと。
- Kubeletポートの露出や監査アラートを無視して認可ルールのみに依存すること。
フォローアップの質問と回答
フォローアップ1：なぜ監視アイデンティティにnodes/proxyを直接付与しないのですか？
nodes/proxyはAPI Server経由でノードエンドポイントへのアクセスを許可するため、メトリクス読み取りよりもはるかに広い範囲をカバーできてしまいます。実際のリクエストパスを確認し、具体的なリソースまたはサブリソースの権限を付与してください。実装上の制約でプロキシアクセスが必要な場合は、専用のアイデンティティにノードスコープの制限と監査アラートを組み合わせて適用します。
フォローアップ2：アップグレードで権限が拡張されていないことをどのように証明しますか？
変更前後の呼び出しマトリクスと認可判定を比較し、新しい動詞、リソース、サブリソース、およびノードスコープに注目します。拒否の差分を分析し、合成リクエストを使用してメトリクスが読み取り可能であり続け、execが拒否されたままであることを証明します。これらのチェックをリリースの判定基準（リリースゲート）とします。
フォローアップ3：認可サービスが利用できなくなった場合はどうなりますか？
明示的なfail-closedポリシーを選択し、コールバックの失敗が許可判定にならないようにします。ビジネス上の許容範囲に応じて、短時間の読み取り専用キャッシュを保持するか収集を一時停止しますが、メトリクスを復旧させるために高リスクなエンドポイントを開放してはなりません。アラートを発報し、コールバックが復旧した後に再検証を行います。