Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第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   ...
Copy to Clipboard Toggle word wrap

より柔軟な方法として、他のツールで処理できる形式でイベントを出力することができます。たとえば、以下の例では 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",
  ...
}
Copy to Clipboard Toggle word wrap

リソースの作成や変更、または削除に関連するイベントも、クラスターの不正な使用を検出するために使用することができます。たとえば、以下のクエリーは、イメージの過剰なプルの有無を確認するために使用できます。 

$ oc get events --all-namespaces -o json \
  | jq '[.items[] | select(.involvedObject.kind == "Pod" and .reason == "Pulling")] | length'

4
Copy to Clipboard Toggle word wrap
注記

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"
Copy to Clipboard Toggle word wrap

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

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

   3288 response="200"
      8 response="404"
      6 response="201"
Copy to Clipboard Toggle word wrap

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

  • 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"
Copy to Clipboard Toggle word wrap

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

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

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat