TKE監査ログ分析
ダウンロード
フォーカスモード
フォントサイズ
概要
Tencent Kubernetes Engine（TKE）は、Tencent Cloudが提供する高性能でスケーラブルなコンテナ管理サービスであり、ユーザーがコンテナ化アプリケーションを容易にデプロイおよび管理できるよう支援します。TKEの使用中、システムは大量の監査ログを生成し、これらのログはクラスタ内の操作行為を詳細に記録します。これにはユーザーのリクエスト、操作時間、リソース変更、アクセス権限などの情報が含まれます（完全なログフィールドの説明については、ログフィールドの説明を参照してください）。CLSはTKEと緊密に統合されており、TKE監査ログをリアルタイムでCLSに収集することをサポートしています。CLSの強力なログ分析能力を活用することで、クラスタのセキュリティとコンプライアンスの監視、操作行為の監査、異常活動の検出、およびリソース使用状況を実現できます。例：
クラスタ内のアプリケーションが削除されました。誰が操作したのかを確認してください。
Apiserverの負荷が突然高くなり、大量のアクセスが失敗しました。クラスタ内で何が発生したのでしょうか。
クラスタノードが封鎖されました。誰がいつ操作したのでしょうか。
本実践を通じて、以下の内容を詳細に理解できます：
以下のデモを通じて、CLSとTKEの強力な連携をすぐに体験することもできます：
監査概要：クラスタ全体のAPIserver操作を観測します。
ノード操作概要：ノード関連の問題の調査に使用します。
K8sオブジェクト操作概要：K8sオブジェクト（例えば特定のワークロード）に関連する問題を調査します。
多次元操作監査分析：あるディメンションにおける監査ログの分布傾向を観測します。
機能メリット
すぐに使えるクラスタ監査分析ダッシュボードです。ダッシュボードには、TKEの操作タイプ分布、操作ステータスコード分布、機密操作ユーザーなどの分析ボードが含まれています。
TKE監査ログの収集
ステップ1：TKEクラウド製品センターに入る
1. CLSコンソールにログインします。
2. 左側のナビゲーションバーでクラウド製品センターをクリックし、クラウド製品センターページに入ります。
3. クラウド製品ログでTKEを見つけ、クリックしてTKEクラウド製品センターに入ります。
ステップ2：TKEクラスター監査ログ収集を有効にする
1. TKEクラウド製品センターで、クラスタリストからターゲットクラスタを見つけます。収集コンポーネントの状態が未インストールの場合は、インストールをクリックして、ログ収集コンポーネントをインストールします。
注意：
ログ収集コンポーネントをインストールすると、クラスタのkube-system名前空間に、DaemonSetとしてtke-log-agentのpodとcls-provisionerのpodが1つずつデプロイされます。各ノードに少なくとも0.1コア、16Mib以上の利用可能なリソースを予約してください。
2. 若采集组件状态为最新、单击集群名称、进入集群详情页、并在集群详情页中找到集群审计日志。
3. 有効化をクリックしてクラスタ監査ログをオンにし、クラスタ監査ログ設定プロセスに入ります。
4. 監査ログ設定プロセスに入り、ログトピック設定ステップで、ログ保存用の既存ログトピックを選択するか、新しく作成できます。ログトピックの関連情報については、ログトピックを参照してください。
5. ログトピックの設定を完了したら、次へをクリックしてインデックス設定に進みます。インデックスの関連情報については、インデックスを参照してください。
インデックス設定の設定情報は以下の通りです：
インデックス状態：インデックスを有効にするかどうかを確認し、ログ検索などの分析機能を使用します。
全文インデックス：大文字と小文字を区別するかどうかを確認します。全文トークナイザ：デフォルトは「@&()='",;:<>[]{}/ \\n\\t\\r」です。変更するかどうかを確認します。
中文が含まれているかどうか：有効にするかどうかを確認します。
キー値インデックス：key名に基づいて、フィールドタイプ、トークナイザ、統計分析を有効にするかどうかを必要に応じて設定できます。キー値インデックスを有効にする必要がある場合は、スイッチをオンにしてください。
注意：
検索を有効にするにはインデックス設定をオンにする必要があります。オンにしない場合は検索できません。
ログフィールドに基づいてログを検索する必要がある場合は、キー値インデックスを設定する必要があります。
ログフィールドに基づいて統計分析を行う必要がある場合は、キー値インデックスを設定し、統計を有効にする必要があります。
インデックスルール編集後は新しく書き込まれたログにのみ適用され、既存データは更新されません。
TKE監査分析ダッシュボードの表示
TKE監査ログ収集を有効にすると、CLSはTKE監査シーン向けに、すぐに利用できる4種類のプリセットダッシュボードを提供します。
監査概要：クラスタ全体のAPIserver操作を観測するために使用されます。
ノード操作概要：ノード関連の問題を調査するために使用します。
K8sオブジェクト操作概要：K8sオブジェクト（例えば特定のワークロード）に関連する問題を調査するために使用します。
多次元操作監査分析：特定のディメンションにおけるクラスタ操作の分布傾向を観測するために使用されます。
以下の操作で上記のTKE監査プリセットダッシュボードを表示できます：
1. CLSコンソールにログインします。
2. 左侧のナビゲーションバーで、ダッシュボード>ダッシュボードリスト>プリセットダッシュボードを選択し、「TKE 監査ログ」を検索します。
クラスター監査ログの検索と分析
1. TKE監査ログ収集を有効にすると、クラスタリストでクラスタ監査ログが有効になっているクラスタを見つけ、クラスタ名をクリックしてクラスタ詳細ページに移動します。
2. クラスタ詳細ページでログ管理をクリックし、クラスタ監査ログモジュールを見つけます。
3. 監査ログをクリックすると、ログ検索ページに移動し、対象クラスタの監査ログを検索分析できます。ログフィールドの説明については、ログフィールドの説明をご参照ください。
ログフィールドの説明
監査ログは、kube-apiserverへのアクセスイベントを記録し、各ユーザー、管理者、またはシステムコンポーネントがクラスタに影響を与えるアクティビティを順番に記録します。各監査ログはJSON形式の構造化レコードであり、メタデータ（metadata）、リクエスト内容（requestObject）、レスポンス内容（responseObject）の3つの部分で構成されます。メタデータ（リクエストのコンテキスト情報、例えば誰がリクエストを発行したか、どこから発行されたか、アクセスしたURIなどの情報を含みます）は必ず存在し、リクエスト内容とレスポンス内容が存在するかどうかは監査レベルによって異なります。ログを通じて以下の内容を確認できます：
クラスタ内で発生するアクティビティ。
アクティビティの発生日時と発生対象。
アクティビティのトリガー時間、トリガー場所、および観測ポイント。
アクティビティの結果とその後の処理動作。
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"RequestResponse","auditID":0a4376d5-307a-4e16-a049-24e017******,"stage":"ResponseComplete",// 何が発生したか"requestURI":"/apis/apps/v1/namespaces/default/deployments","verb":"create",// 誰が発行したか"user":{"username":"admin","uid":"admin","groups":["system:masters","system:authenticated"]},// どこから発行されたか"sourceIPs":["10.0.6.68"],"userAgent":"kubectl/v1.16.3 (linux/amd64) kubernetes/ald64d8",}"objectRef":{"resource":"deployments","namespace":"default","name":"nginx-deployment","apiGroup":"apps","apiVersion":"v1"},// 結果は何か"responseStatus":{"metadata":{},"code":201},// リクエストおよびレスポンスの具体的な情報"requestObject":Object{...},"responseObject":Object{...},// いつ開始/終了するか"requestReceivedTimestamp":"20xx-04-10T10:47:34.315746Z","stageTimestamp":"20xx-04-10T10:47:34.328942Z",// リクエストが受け付けられた/拒否された理由は何か"annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
実践シナリオ事例
事例1：クラスター内のNginxアプリケーションが削除されました。誰が操作したのですか？
1. TKE監査分析ダッシュボードの確認を参照し、K8sオブジェクト操作概要ダッシュボードを開き、ログトピックで監査ログが保存されているログトピックを選択し、操作タイプとしてdelete、リソースオブジェクトとしてnginxを指定します。
2. 重要操作リストグラフでは、クエリ結果は以下の図の通りです：
図から分かるように、削除を実行したのはアカウント
10001****7138であり、このアカウントがアプリケーション「nginx」に対して削除を行いました。アカウントIDに基づいて、CAM > ユーザー > ユーザーリストでこのアカウントに関する詳細情報を確認できます。事例2：Apiserverの負荷が突然高くなり、大量のアクセスが失敗しました。クラスター内で何が起きたのですか？
1. TKE監査分析ダッシュボードの確認を参照して、集計検索ダッシュボードを開きます。このダッシュボードは、ユーザー、操作タイプ、戻りステータスコードなどの多次元からApiserverアクセスの集計トレンドグラフを提供します。
操作ユーザー分布トレンドグラフ：
操作タイプ分布トレンドグラフ：
ステータスコード分布トレンドグラフ：
2. 以上のグラフから、ユーザー
tke-kube-state-metricsのアクセス量が他ユーザーよりはるかに高く、「操作タイプ分布トレンド」グラフではそのほとんどがlist操作であることが分かります。「ステータスコード分布トレンド」グラフでは、ステータスコードのほとんどが403であることが分かります。tke-kube-state-metricsキーワードに基づいてログを検索します。
ビジネスログと合わせると、RBAC認証の問題によりtke-kube-state-metricsコンポーネントが継続的にApiserverへ再試行リクエストを行い、Apiserverへのアクセスが急増したことが分かります。事例3：クラスターノードが封鎖されました。誰がいつ操作したのですか？
1. TKE監査分析ダッシュボードの確認を参照し、ノード操作概要ダッシュボードを開き、封鎖されたノード名を入力します。
2. 封锁操作リストグラフでは、クエリ結果は以下の図の通りです：
図から分かるように、
20xx-xx-30T06:22:18に、アカウント10001****7138がノード172.16.18.13に対して封鎖操作を実行しました。
フィードバック