10.3.2. マスター API の監査ログ


ユーザー、管理者またはシステムコンポーネントによるマスター API 要求をログに記録するには、マスター API の 監査ロギングを有効にします。これにより、各マスターホストにファイルが作成されるか、またはファイルが設定されない場合は、ファイルはサービスジャーナルに含まれます。ジャーナルのエントリーは "AUDIT" を検索して見つけることができます。

監査ログのエントリー は、受信時にそれぞれの REST 要求を記録する 1 行と、完了時の HTTP レスポンスコードの 1 行で設定されます。以下の例では、システム管理者によるノード一覧を要求時の記録を示しています。

2017-10-17T13:12:17.635085787Z AUDIT: id="410eda6b-88d4-4491-87ff-394804ca69a1" ip="192.168.122.156" method="GET" user="system:admin" groups="\"system:cluster-admins\",\"system:authenticated\"" as="<self>" asgroups="<lookup>" namespace="<none>" uri="/api/v1/nodes"
2017-10-17T13:12:17.636081056Z AUDIT: id="410eda6b-88d4-4491-87ff-394804ca69a1" response="200"

以下の例で示すように、レスポンスコードごとに最新要求の数についての定期的なログのポーリングが役に立つ場合があります。

$ tail -5000 /var/log/origin/audit-ocp.log \
  | grep -Po 'response="..."' \
  | sort | uniq -c | sort -rn

   3288 response="200"
      8 response="404"
      6 response="201"

以下の一覧は、レスポンスコードのいくつかについて詳しく説明しています。

  • 200 または 201 のレスポンスコードは、要求が正常であることを示します。
  • 400 のレスポンスコードは、大半のクライアントでは発生するはずのない不正な要求を示すので、留意する必要のあるコードです。
  • 404 のレスポンスコードは通常、存在しないリソースに対する無害な要求です。
  • 500 - 599 のレスポンスコードは、サーバーエラーを示します。 これは、バグやシステム障害、または悪意のあるアクティビティーの結果として生じる場合があります。

エラーのレスポンス数が異常に多い場合には、対応する要求の監査ログエントリーを取得してさらに調査することができます。

注記

要求の IP アドレスは通常、クラスターホストまたは API ロードバランサーです。ロードバランサープロキシー要求の背後には IP アドレスの記録がありません (ただし、ロードバランサーのログは、要求元を判別するのに役立つことがあります)。

異常な数の要求については、特定のユーザーまたはグループごとに調べるのが適している場合があります。

以下の例では、監査ログの最後の 5000 行での要求数において上位 10 位のユーザーを表示しています。

$ tail -5000 /var/log/origin/audit-ocp.log \
  | grep -Po ' user="(.*?)(?<!\\)"' \
  | sort | uniq -c | sort -rn | head -10

  976  user="system:openshift-master"
  270  user="system:node:origin-node-1.example.local"
  270  user="system:node:origin-master.example.local"
   66  user="system:anonymous"
   32  user="system:serviceaccount:kube-system:cronjob-controller"
   24  user="system:serviceaccount:kube-system:pod-garbage-collector"
   18  user="system:serviceaccount:kube-system:endpoint-controller"
   14  user="system:serviceaccount:openshift-infra:serviceaccount-pull-secrets-controller"
   11  user="test user"
    4  user="test \" user"

通常は、さらに詳細なクエリーを実行するには追加のログ解析ツールを使用する必要があります。監査担当者は OpenShift v1 API および Kubernetes v1 API に精通し、関連するリソースの種類 (uri フィールド) に応じて要求の要約を監査ログから集計できるようにしておく必要があります。詳細は、REST API Reference を参照してください。

高度な監査ロギング機能 を利用することができます。この機能により、ログに記録する要求やログの詳細レベルを制御するための監査ポリシーファイルの提供が可能になります。高度な監査ログのエントリーは JSON 形式で詳細情報を提供し、ファイルまたはシステムジャーナルではなく Webhook を使用してログに記録することができます。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.