第10章 クラスターイベントとログの監視
10.1. はじめに
本書の他のセクションで説明されているセキュリティー対策のほかにも、OpenShift Container Platform クラスターを監視および監査する機能は、不適切な利用に対してクラスターおよびそのユーザーを保護する上で重要な要素となります。
これに関連し、イベントとログという 2 つの主な情報源をクラスターレベルの情報として使用できます。
10.2. クラスターのイベント
クラスター管理者は、関連するイベントを判別できるように イベント のリソースタイプについて理解し、イベントの一覧 を確認することをお勧めします。マスターコントローラーおよびプラグインの設定によっては、ここに一覧表示されているものよりも、多くのイベントタイプが使用される可能性があります。
イベントは、関連するリソースの namespace または デフォルト の namespace (クラスターイベントの場合) のいずれかの namespace に関連付けられます。デフォルト の namespace は、クラスターを監視または監査するための関連するイベントを保持します。たとえば、これには ノード イベントおよびインフラストラクチャーコンポーネントに関連したリソースイベントが含まれます。
マスター API および oc コマンドは、イベントの一覧をノードに関連するものに制限するパラメーターを提供しません。これを実行する簡単な方法として grep を使用することができます。
$ oc get event -n default | grep Node 1h 20h 3 origin-node-1.example.local Node Normal NodeHasDiskPressure ...
より柔軟な方法として、他のツールで処理できる形式でイベントを出力することができます。たとえば、以下の例では NodeHasDiskPressure イベントのみを展開するために JSON 出力に対してjq ツールを使用しています。
$ oc get events -n default -o json \
| jq '.items[] | select(.involvedObject.kind == "Node" and .reason == "NodeHasDiskPressure")'
{
"apiVersion": "v1",
"count": 3,
"involvedObject": {
"kind": "Node",
"name": "origin-node-1.example.local",
"uid": "origin-node-1.example.local"
},
"kind": "Event",
"reason": "NodeHasDiskPressure",
...
}リソースの作成や変更、または削除に関連するイベントも、クラスターの不正な使用を検出するために使用することができます。たとえば、以下のクエリーは、イメージの過剰なプルの有無を確認するために使用できます。
$ oc get events --all-namespaces -o json \ | jq '[.items[] | select(.involvedObject.kind == "Pod" and .reason == "Pulling")] | length' 4
namespace が削除されると、そのイベントも削除されます。イベントも期限切れとなり、etcd ストレージが一杯にならないように削除されます。イベントは永続するレコードとして保存されず、一定期間の統計データを取得するためにポーリングを頻繁に実行することが必要になります。
10.3. クラスターのログ
このセクションでは、クラスターで生成される運用ログの種類について説明します。
10.3.1. サービスログ
OpenShift Container Platform は、ホストで実行されている各 systemd サービスと共にログを作成します。
- atomic-openshift-master-api
- atomic-openshift-master-controllers
- etcd
- atomic-openshift-node
これらのログは、セキュリティー監査よりもデバッグを目的として用意されています。これらは、journalctl を使ってホストごとに取得するか、またはクラスター内ではクラスター管理者として、ロギング .operations インデックス (Ops クラスター 内の場合がある) にデプロイされた集計ロギングスタックを使って取得できます。
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/openshift-audit.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/openshift-audit.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』を参照してください。
高度な監査ロギング機能 は、OpenShift Container Platform 3.7 では テクノロジープレビュー 機能として導入されています。 この機能により、ログに記録する要求やログの詳細レベルを制御するための監査ポリシーファイルの提供が可能になります。高度な監査ログのエントリーは JSON 形式で詳細情報を提供し、ファイルまたはシステムジャーナルではなく Webhook を使用してログに記録することができます。
