Red Hat Developer Hub の監査ログ
Red Hat Developer Hub 監査ログを使用して、ユーザーアクティビティー、システムイベント、データ変更を追跡する
概要
第1章 Red Hat Developer Hub の監査ログ
監査ログは、Red Hat Developer Hub のユーザー、管理者、またはコンポーネントに影響するユーザーアクティビティー、システムイベント、およびデータ変更を記録した時系列のレコードのセットです。管理者は、OpenShift Container Platform Web コンソールで Developer Hub 監査ログを表示して、scaffolder イベント、RBAC システムの変更、カタログデータベースの変更を監視できます。監査ログには次の情報が含まれます。
- 監査対象イベントの名前
- 監査対象イベントをトリガーしたアクター (ターミナル、ポート、IP アドレス、ホスト名など)
- イベントのメタデータ (日付、時刻など)
-
イベントのステータス (
success
、failure
など) -
重大度 (
info
、debug
、warn
、error
など)
監査ログの情報を使用すると、次の目的を達成できます。
- セキュリティーの強化
- 自動化システムやソフトウェアテンプレートによって開始されたアクティビティーも含め、アクティビティーをソースまで追跡できます。ソフトウェアテンプレートがいつ実行するか、またアプリケーションとコンポーネントのインストール、更新、設定の変更、削除の詳細を把握できます。
- コンプライアンスの自動化
- 効率的なプロセスを使用して、監査目的または継続的なコンプライアンス維持のために、特定の時点のログデータを表示できます。
- 問題のデバッグ
- アクセスレコードとアクティビティーの詳細を使用して、ソフトウェアテンプレートやプラグインの問題を修正できます。
監査ログは、デフォルトでは内部ログストアに転送されません。内部ログストアには、セキュアなストレージがないためです。お客様の責任において、監査ログを転送するシステムが組織および政府の規制に準拠し、適切に保護されていることを確認してください。
第2章 OpenShift Container Platform に Developer Hub 用監査ログの設定
OpenShift Container Platform Web コンソールを使用して、Developer Hub の監査ログを使用するように次の OpenShift Container Platform ロギングコンポーネントを設定します。
- ロギングのデプロイメント
- 各ロギングコンポーネントの CPU とメモリーの制限を含むロギング環境を設定します。詳細は、Red Hat OpenShift Container Platform - ロギングデプロイメントの設定 を参照してください。
- ロギングコレクター
-
ClusterLogging
カスタムリソース (CR) のspec.collection
スタンザを設定して、サポートされているログコレクターの変更を使用し、STDOUT
からログを収集します。詳細は、Red Hat OpenShift Container Platform - ログコレクターの設定 を参照してください。 - ログ転送
-
ClusterLogForwarder
CR で出力とパイプラインの組み合わせを指定して、OpenShift Container Platform クラスター内外の特定のエンドポイントにログを送信します。詳細は、Red Hat OpenShift Container Platform - JSON ログ転送の有効化 および Red Hat OpenShift Container Platform - ログ転送の設定 を参照してください。
2.1. Red Hat Developer Hub 監査ログを Splunk に転送
Red Hat OpenShift Logging (OpenShift Logging) Operator と ClusterLogForwarder
インスタンスを使用して、Developer Hub インスタンスからストリーミングされた監査ログをキャプチャーし、Splunk インスタンスに関連付けられた HTTPS エンドポイントに転送できます。
前提条件
- サポートされている OpenShift Container Platform バージョンでクラスターが実行している。
-
cluster-admin
権限を持つアカウントがある。 - Splunk Cloud アカウントまたは Splunk Enterprise インストールをもっている。
手順
- OpenShift Container Platform クラスターにログインします。
OpenShift Logging Operator を
openshift-logging
namespace にインストールし、namespace に切り替えます。namespace に切り替えるコマンドの例
oc project openshift-logging
oc project openshift-logging
Copy to Clipboard Copied! log-collector
という名前のserviceAccount
を作成し、collect-application-logs
ロールをserviceAccount
にバインドします。serviceAccount
を作成するためのコマンド例oc create sa log-collector
oc create sa log-collector
Copy to Clipboard Copied! ロールを
serviceAccount
にバインドするコマンドの例oc create clusterrolebinding log-collector --clusterrole=collect-application-logs --serviceaccount=openshift-logging:log-collector
oc create clusterrolebinding log-collector --clusterrole=collect-application-logs --serviceaccount=openshift-logging:log-collector
Copy to Clipboard Copied! -
Splunk インスタンスで
hecToken
を生成します。 openshift-logging
namespace にキー/値シークレットを作成し、そのシークレットを検証します。hecToken
を使用してキー/値シークレットを作成するコマンドの例oc -n openshift-logging create secret generic splunk-secret --from-literal=hecToken=<HEC_Token>
oc -n openshift-logging create secret generic splunk-secret --from-literal=hecToken=<HEC_Token>
Copy to Clipboard Copied! 秘密を検証するコマンドの例
oc -n openshift-logging get secret/splunk-secret -o yaml
oc -n openshift-logging get secret/splunk-secret -o yaml
Copy to Clipboard Copied! 次のように、基本的な `ClusterLogForwarder` リソース YAML ファイルを作成します。
`ClusterLogForwarder` リソースの YAML ファイルの例
apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging
apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: name: instance namespace: openshift-logging
Copy to Clipboard Copied! 詳細は、ログフォワーダーの作成 を参照してください。
OpenShift Web コンソールまたは OpenShift CLI を使用して、次の
ClusterLogForwarder
設定を定義します。YAML ファイルで、
log-collector
をserviceAccount
として指定します。serviceAccount
設定例serviceAccount: name: log-collector
serviceAccount: name: log-collector
Copy to Clipboard Copied! 転送するログの種類とソースを指定するには、
inputs
を設定します。次の設定により、フォワーダーは指定された namespace 内のすべてのアプリケーションからログをキャプチャーできるようになります。inputs
設定の例inputs: - name: my-app-logs-input type: application application: includes: - namespace: my-rhdh-project containerLimit: maxRecordsPerSecond: 100
inputs: - name: my-app-logs-input type: application application: includes: - namespace: my-rhdh-project containerLimit: maxRecordsPerSecond: 100
Copy to Clipboard Copied! 詳細は、特定の Pod からのアプリケーションログの転送 を参照してください。
出力を設定して、キャプチャーされたログの送信先を指定します。このステップでは、
splunk
タイプに焦点を当てます。Splunk エンドポイントが自己署名 TLS 証明書を使用する場合はtls.insecureSkipVerify
オプションを使用するか (非推奨)、Secret を使用して証明書チェーンを提供できます。outputs
設定の例outputs: - name: splunk-receiver-application type: splunk splunk: authentication: token: key: hecToken secretName: splunk-secret index: main url: 'https://my-splunk-instance-url' rateLimit: maxRecordsPerSecond: 250
outputs: - name: splunk-receiver-application type: splunk splunk: authentication: token: key: hecToken secretName: splunk-secret index: main url: 'https://my-splunk-instance-url' rateLimit: maxRecordsPerSecond: 250
Copy to Clipboard Copied! 詳細は、OpenShift Container Platform ドキュメントの Splunk へのログの転送 を参照してください。
オプション: 監査ログのみを含めるようにログをフィルタリングします。
filters
設定例filters: - name: audit-logs-only type: drop drop: - test: - field: .message notMatches: isAuditLog
filters: - name: audit-logs-only type: drop drop: - test: - field: .message notMatches: isAuditLog
Copy to Clipboard Copied! 詳細は、OpenShift Container Platform ドキュメントの コンテンツによるログのフィルタリング を参照してください。
特定の入力から指定された出力にログをルーティングするようにパイプラインを設定します。定義された入力と出力の名前を使用して、各パイプラインで複数の
inputRefs
とoutputRefs
を指定します。pipelines
設定の例pipelines: - name: my-app-logs-pipeline detectMultilineErrors: true inputRefs: - my-app-logs-input outputRefs: - splunk-receiver-application filterRefs: - audit-logs-only
pipelines: - name: my-app-logs-pipeline detectMultilineErrors: true inputRefs: - my-app-logs-input outputRefs: - splunk-receiver-application filterRefs: - audit-logs-only
Copy to Clipboard Copied!
ClusterLogForwarder
設定を適用するには、次のコマンドを実行します。ClusterLogForwarder
設定を適用するコマンドの例oc apply -f <ClusterLogForwarder-configuration.yaml>
oc apply -f <ClusterLogForwarder-configuration.yaml>
Copy to Clipboard Copied! オプション: ログ損失のリスクを軽減するには、次のオプションを使用して
ClusterLogForwarder
Pod を設定します。ログコレクターのリソース要求と制限を次のように定義します。
collector
設定の例collector: resources: requests: cpu: 250m memory: 64Mi ephemeral-storage: 250Mi limits: cpu: 500m memory: 128Mi ephemeral-storage: 500Mi
collector: resources: requests: cpu: 250m memory: 64Mi ephemeral-storage: 250Mi limits: cpu: 500m memory: 128Mi ephemeral-storage: 500Mi
Copy to Clipboard Copied! delivery
、compression
、RetryDuration
など、ログ配信のtuning
オプションを定義します。必要に応じて出力ごとにチューニングを適用できます。tuning
設定の例tuning: delivery: AtLeastOnce compression: none minRetryDuration: 1s maxRetryDuration: 10s
tuning: delivery: AtLeastOnce
1 compression: none minRetryDuration: 1s maxRetryDuration: 10s
Copy to Clipboard Copied! - 1
AtLeastOnce
配信モードとは、ログフォワーダーがクラッシュしたり再起動したりした場合に、クラッシュ前に読み取られたにもかかわらず宛先に送信されなかったログが、再送信されることを意味します。クラッシュ後に一部のログが重複している可能性があります。
検証
- Splunk ダッシュボードでログを表示して、ログが Splunk インスタンスに転送されていることを確認します。
- 必要に応じて、OpenShift Container Platform と Splunk ログを使用して問題をトラブルシューティングします。
第3章 Developer Hub の監査ログの表示
管理者は、Red Hat OpenShift Container Platform Web コンソールからログデータを表示、検索、フィルタリング、管理できます。isAuditLog
フィールドを使用して、監査ログを他のログタイプからフィルタリングできます。
前提条件
- OpenShift Container Platform Web コンソールに管理者としてログインしている。
手順
- OpenShift Container Platform Web コンソールの Developer 視点から、Topology タブをクリックします。
- Topology ビューから、監査ログデータを表示する Pod をクリックします。
- Pod パネルから、Resources タブをクリックします。
- Resources タブの Pods セクションで、View logs をクリックします。
-
Logs ビューから、Search フィールドに
isAuditLog
と入力して、監査ログを他のログタイプからフィルタリングします。矢印を使用して、isAuditLog
フィールドを含むログを参照できます。
3.1. 監査ログフィールド
Developer Hub の監査ログには、次のフィールドを含めることができます。
eventName
- 監査対象イベントの名前。
actor
監査対象イベントをトリガーしたアクターに関する情報を含むオブジェクト。次のフィールドが含まれます。
actorId
-
関連付けられたユーザーまたはサービスの名前/ID/
entityRef
。認証されていないユーザーがエンドポイントにアクセスし、デフォルトの認証ポリシーが無効になっている場合は、null
になることがあります。 ip
- アクターの IP アドレス (任意)。
hostname
- アクターのホスト名 (任意)。
client
- アクターのユーザーエージェント (任意)。
stage
-
監査ログが生成された時点のイベントの段階 (
initiation
、completion
など)。 status
-
イベントのステータス (
succeeded
、failed
など)。 meta
-
イベント固有のデータ (
taskId
など) を含むオプションのオブジェクト。 request
エンドポイントに送信された HTTP リクエストに関する情報を含む任意のフィールド。次のフィールドが含まれます。
method
- リクエストの HTTP メソッド。
query
-
リクエストの
query
フィールド。 params
-
リクエストの
params
フィールド。 body
-
リクエストの
body
。タスクの作成時に指定されたsecrets
はリダクションされ、*
と表示されます。 url
- リクエストのエンドポイント URL。
response
エンドポイントから送信された HTTP レスポンスに関する情報を含む任意のフィールド。次のフィールドが含まれます。
status
- HTTP レスポンスのステータスコード。
body
- リクエストボディーの内容。
isAuditLog
-
監査ログを他のログタイプと区別するために
true
に設定されるフラグ。 errors
-
エラーの
name
、message
、および場合によってはエラーのstack
フィールドを含むエラーのリスト。status
がfailed
の場合にのみ表示されます。
3.2. scaffolder イベント
Developer Hub 監査ログには、次の scaffolder イベントを含めることができます。
ScaffolderParameterSchemaFetch
-
テンプレートパラメータースキーマを返す、
/v2/templates/:namespace/:kind/:name/parameter-schema
エンドポイントへのGET
リクエストを追跡します。 ScaffolderInstalledActionsFetch
-
インストールされたアクションのリストを取得する、
/v2/actions
エンドポイントへのGET
リクエストを追跡します。 ScaffolderTaskCreation
-
scaffolder が実行するタスクを作成する、
/v2/tasks
エンドポイントへのPOST
リクエストを追跡します。 ScaffolderTaskListFetch
-
scaffolder 内の全タスクの詳細を取得する、
/v2/tasks
エンドポイントへのGET
リクエストを追跡します。 ScaffolderTaskFetch
-
指定のタスク
:taskId
の詳細を取得する、/v2/tasks/:taskId
エンドポイントへのGET
リクエストを追跡します。 ScaffolderTaskCancellation
-
実行中のタスクをキャンセルする、
/v2/tasks/:taskId/cancel
エンドポイントへのPOST
リクエストを追跡します。 ScaffolderTaskStream
-
タスク
:taskId
のタスクログのイベントストリームを返す、/v2/tasks/:taskId/eventstream
エンドポイントへのGET
リクエストを追跡します。 ScaffolderTaskEventFetch
-
タスク
:taskId
のタスクログのスナップショットを返す、/v2/tasks/:taskId/events
エンドポイントへのGET
リクエストを追跡します。 ScaffolderTaskDryRun
-
ドライランタスクを作成する、
/v2/dry-run
エンドポイントへのPOST
リクエストを追跡します。ドライランに関連付けられたイベントのすべての監査ログでは、meta.isDryLog
フラグがtrue
に設定されます。 ScaffolderStaleTaskCancellation
- 古いタスクの自動キャンセルを追跡します。
ScaffolderTaskExecution
-
実際の scaffolder タスク実行の
initiation
とcompletion
を追跡します (ドライラン時には追跡しません)。 ScaffolderTaskStepExecution
-
scaffolder タスクステップ実行の
initiation
とcompletion
を追跡します。 ScaffolderTaskStepSkip
-
if
条件が満たされず、スキップされたステップを追跡します。 ScaffolderTaskStepIteration
-
each
フィールドを含むタスクステップの各イテレーションのステップ実行を追跡します。
3.3. カタログイベント
Developer Hub 監査ログには、次のカタログイベントを含めることができます。
CatalogEntityAncestryFetch
-
エンティティーの祖先を返す、
/entities/by-name/:kind/:namespace/:name/ancestry
エンドポイントへのGET
リクエストを追跡します。 CatalogEntityBatchFetch
-
エンティティーのバッチを返す、
/entities/by-refs
エンドポイントへのPOST
リクエストを追跡します。 CatalogEntityDeletion
-
エンティティーを削除する、
/entities/by-uid/:uid
エンドポイントへのDELETE
リクエストを追跡します。
削除するエンティティーの親のロケーションがカタログ内に存在する場合は、エンティティーが次の処理サイクル時に、カタログ内に復元されます。
CatalogEntityFacetFetch
-
エンティティーのファセットを返す、
/entity-facets
エンドポイントへのGET
リクエストを追跡します。 CatalogEntityFetch
-
エンティティーのリストを返す、
/entities
エンドポイントへのGET
リクエストを追跡します。 CatalogEntityFetchByName
-
指定のエンティティー参照 (例:
<kind>:<namespace>/<name>)
に一致するエンティティーを返す、/entities/by-name/:kind/:namespace/:name
エンドポイントへのGET
リクエストを追跡します。 CatalogEntityFetchByUid
-
指定エンティティーの一意の ID に一致するエンティティーを返す、
/entities/by-uid/:uid
エンドポイントへのGET
リクエストを追跡します。 CatalogEntityRefresh
-
指定のエンティティーの更新をスケジュールする、
/entities/refresh
エンドポイントへのPOST
リクエストを追跡します。 CatalogEntityValidate
-
指定のエンティティーを検証する、
/entities/validate
エンドポイントへのPOST
リクエストを追跡します。 CatalogLocationCreation
-
ロケーションを作成する、
/locations
エンドポイントへのPOST
リクエストを追跡します。
ロケーションとは、カタログデータを検索するために他の場所を参照するマーカーです。
CatalogLocationAnalyze
-
指定のロケーションを分析する、
/locations/analyze
エンドポイントへのPOST
リクエストを追跡します。 CatalogLocationDeletion
-
ロケーションとそれに関連付けられたすべての子エンティティーを削除する、
/locations/:id
エンドポイントへのDELETE
リクエストを追跡します。 CatalogLocationFetch
-
/locations
エンドポイントへのGET
リクエストを追跡します。 CatalogLocationFetchByEntityRef
-
指定のエンティティー参照に関連付けられたロケーションのリストを返す、
/locations/by-entity
エンドポイントへのGET
リクエストを追跡します。 CatalogLocationFetchById
-
指定のロケーション ID に一致するロケーションを返す、
/locations/:id
エンドポイントへのGET
リクエストを追跡します。 QueriedCatalogEntityFetch
-
指定のクエリーに一致するエンティティーのリストを返す、
/entities/by-query
エンドポイントへのGET
リクエストを追跡します。