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 を使用してログに記録することができます。