6.6. File Integrity Operator について

PDF

File Integrity Operator は OpenShift Container Platform Operator であり、クラスターノード上でファイルの整合性チェックを継続的に実行します。これは、各ノードで特権付きの AIDE (advanced intrusion detection environment; 高度な侵入検知環境) コンテナーを各ノードで初期化し、実行するデーモンセットをデプロイし、ステータスオブジェクトをデーモンセット Pod の初回実行時に変更されるファイルのログと共に提供します。

重要

現時点では、Red Hat Enterprise Linux CoreOS (RHCOS) ノードのみがサポートされます。

6.6.1. FileIntegrity カスタムリソースの作成

FileIntegrity カスタムリソース (CR) のインスタンスは、1 つ以上のノードの継続的なファイル整合性スキャンのセットを表します。

それぞれの FileIntegrity CR は、FileIntegrity CR 仕様に一致するノード上で AIDE を実行するデーモンセットによってサポートされます。

手順

worker-fileintegrity.yaml という名前の次の例の FileIntegrity CR を作成して、ワーカーノードでのスキャンを有効にします。

サンプル FileIntegrity CR

apiVersion: fileintegrity.openshift.io/v1alpha1
kind: FileIntegrity
metadata:
  name: worker-fileintegrity
  namespace: openshift-file-integrity
spec:
  nodeSelector: 1
      node-role.kubernetes.io/worker: ""
  tolerations: 2
  - key: "myNode"
    operator: "Exists"
    effect: "NoSchedule"
  config: 3
    name: "myconfig"
    namespace: "openshift-file-integrity"
    key: "config"
    gracePeriod: 20 4
    maxBackups: 5 5
    initialDelay: 60 6
  debug: false
status:
  phase: Active 7

1: ノードスキャンをスケジュールするためのセレクターを定義します。
2: カスタムテイントを持つノードにスケジュールする tolerations を指定します。指定しない場合、メインノードとインフラノードでの実行を許可するデフォルトの容認が適用されます。
3: 使用する AIDE 設定を含む ConfigMap を定義します。
4: AIDE 整合性チェックの間に一時停止する秒数。ノード上で AIDE チェックを頻繁に実行すると、多くのリソースが消費する可能性があるため、間隔をより長く指定することができます。デフォルトは 900 秒 (15 分) です。
5: ノードで保持する re-init プロセスから残った AIDE データベースとログのバックアップの最大数。この数を超える古いバックアップは、デーモンによって自動的に削除されます。デフォルトは 5 に設定されています。
6: 最初の AIDE 整合性チェックを開始するまで待機する秒数。デフォルトは 0 に設定されています。
7: FileIntegrity インスタンスの実行ステータス。ステータスは、Initializing、Pending、または Active です。

`Initializing`	`FileIntegrity` オブジェクトは現在、AIDE データベースを初期化または再初期化しています。
`Pending`	`FileIntegrity` デプロイメントはまだ作成中です。
`Active`	スキャンはアクティブで進行中です。

YAML ファイルを openshift-file-integrity namespace に適用します。
```
$ oc apply -f worker-fileintegrity.yaml -n openshift-file-integrity
```

検証

次のコマンドを実行して、FileIntegrity オブジェクトが正常に作成されたことを確認します。
```
$ oc get fileintegrities -n openshift-file-integrity
```
出力例
```
NAME                   AGE
worker-fileintegrity   14s
```

6.6.2. FileIntegrity カスタムリソースのステータスの確認

FileIntegrity カスタムリソース (CR) は、.status.phase サブリソースでそのステータスを報告します。

手順

FileIntegrity CR ステータスをクエリーするには、以下を実行します。
```
$ oc get fileintegrities/worker-fileintegrity  -o jsonpath="{ .status.phase }"
```
出力例
```
Active
```

6.6.3. FileIntegrity カスタムリソースの各種フェーズ

Pending: カスタムリソース (CR) の作成後のフェーズ。
Active: バッキングデーモンセットが実行するフェーズ。
Initializing: AIDE データベースが再初期化されるフェーズ。

6.6.4. FileIntegrityNodeStatuses オブジェクトについて

FileIntegrity CR のスキャン結果は、FileIntegrityNodeStatuses という別のオブジェクトで報告されます。

$ oc get fileintegritynodestatuses

出力例

NAME                                                AGE
worker-fileintegrity-ip-10-0-130-192.ec2.internal   101s
worker-fileintegrity-ip-10-0-147-133.ec2.internal   109s
worker-fileintegrity-ip-10-0-165-160.ec2.internal   102s

注記

FileIntegrityNodeStatus オブジェクトの結果が利用可能になるまで、しばらく時間がかかる場合があります。

ノードごとに 1 つの結果オブジェクトがあります。それぞれの FileIntegrityNodeStatus オブジェクトの nodeName 属性は、スキャンされるノードに対応します。ファイル整合性スキャンのステータスは、スキャン条件を保持する results 配列で表示されます。

$ oc get fileintegritynodestatuses.fileintegrity.openshift.io -ojsonpath='{.items[*].results}' | jq

fileintegritynodestatus オブジェクトは AIDE 実行の最新のステータスを報告し、status フィールドに Failed、Succeeded、または Errored などのステータスを公開します。

$ oc get fileintegritynodestatuses -w

出力例

NAME                                                               NODE                                         STATUS
example-fileintegrity-ip-10-0-134-186.us-east-2.compute.internal   ip-10-0-134-186.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-150-230.us-east-2.compute.internal   ip-10-0-150-230.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-169-137.us-east-2.compute.internal   ip-10-0-169-137.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-180-200.us-east-2.compute.internal   ip-10-0-180-200.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-194-66.us-east-2.compute.internal    ip-10-0-194-66.us-east-2.compute.internal    Failed
example-fileintegrity-ip-10-0-222-188.us-east-2.compute.internal   ip-10-0-222-188.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-134-186.us-east-2.compute.internal   ip-10-0-134-186.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-222-188.us-east-2.compute.internal   ip-10-0-222-188.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-194-66.us-east-2.compute.internal    ip-10-0-194-66.us-east-2.compute.internal    Failed
example-fileintegrity-ip-10-0-150-230.us-east-2.compute.internal   ip-10-0-150-230.us-east-2.compute.internal   Succeeded
example-fileintegrity-ip-10-0-180-200.us-east-2.compute.internal   ip-10-0-180-200.us-east-2.compute.internal   Succeeded

6.6.5. FileIntegrityNodeStatus CR ステータスタイプ

これらの条件は、対応する FileIntegrityNodeStatus CR ステータスの results 配列で報告されます。

Succeeded: 整合性チェックにパスしました。データベースが最後に初期化されてから、AIDE チェックの対象となるファイルおよびディレクトリーは変更されていません。
Failed: 整合性チェックにパスしません。データベースが最後に初期化されてから、AIDE チェックの対象となるファイルまたはディレクトリーが変更されています。
Errored: AIDE スキャナーで内部エラーが発生しました。

6.6.5.1. FileIntegrityNodeStatus CR の成功例

成功ステータスのある状態の出力例

[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:45:57Z"
  }
]
[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:46:03Z"
  }
]
[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:45:48Z"
  }
]

この場合、3 つのスキャンがすべて正常に実行され、現時点ではその他の状態は存在しません。

6.6.5.2. FileIntegrityNodeStatus CR の失敗ステータスの例

障害のある状態をシミュレートするには、AIDE が追跡するファイルの 1 つを変更します。たとえば、ワーカーノードのいずれかで /etc/resolv.conf を変更します。

$ oc debug node/ip-10-0-130-192.ec2.internal

出力例

Creating debug namespace/openshift-debug-node-ldfbj ...
Starting pod/ip-10-0-130-192ec2internal-debug ...
To use host binaries, run `chroot /host`
Pod IP: 10.0.130.192
If you don't see a command prompt, try pressing enter.
sh-4.2# echo "# integrity test" >> /host/etc/resolv.conf
sh-4.2# exit

Removing debug pod ...
Removing debug namespace/openshift-debug-node-ldfbj ...

しばらくすると、Failed 状態が対応する FileIntegrityNodeStatus オブジェクトの results 配列で報告されます。前回の Succeeded 状態は保持されるため、チェックが失敗した時間を特定することができます。

$ oc get fileintegritynodestatuses.fileintegrity.openshift.io/worker-fileintegrity-ip-10-0-130-192.ec2.internal -ojsonpath='{.results}' | jq -r

または、オブジェクト名に言及していない場合は、以下を実行します。

$ oc get fileintegritynodestatuses.fileintegrity.openshift.io -ojsonpath='{.items[*].results}' | jq

出力例

[
  {
    "condition": "Succeeded",
    "lastProbeTime": "2020-09-15T12:54:14Z"
  },
  {
    "condition": "Failed",
    "filesChanged": 1,
    "lastProbeTime": "2020-09-15T12:57:20Z",
    "resultConfigMapName": "aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed",
    "resultConfigMapNamespace": "openshift-file-integrity"
  }
]

Failed 状態は、失敗した内容と理由に関する詳細を示す設定マップを参照します。

$ oc describe cm aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed

出力例

Name:         aide-ds-worker-fileintegrity-ip-10-0-130-192.ec2.internal-failed
Namespace:    openshift-file-integrity
Labels:       file-integrity.openshift.io/node=ip-10-0-130-192.ec2.internal
              file-integrity.openshift.io/owner=worker-fileintegrity
              file-integrity.openshift.io/result-log=
Annotations:  file-integrity.openshift.io/files-added: 0
              file-integrity.openshift.io/files-changed: 1
              file-integrity.openshift.io/files-removed: 0

Data

integritylog:
------
AIDE 0.15.1 found differences between database and filesystem!!
Start timestamp: 2020-09-15 12:58:15

Summary:
  Total number of files:  31553
  Added files:                0
  Removed files:            0
  Changed files:            1


---------------------------------------------------
Changed files:
---------------------------------------------------

changed: /hostroot/etc/resolv.conf

---------------------------------------------------
Detailed information about changes:
---------------------------------------------------


File: /hostroot/etc/resolv.conf
 SHA512   : sTQYpB/AL7FeoGtu/1g7opv6C+KT1CBJ , qAeM+a8yTgHPnIHMaRlS+so61EN8VOpg

Events:  <none>

設定マップのデータサイズの制限により、1 MB を超える AIDE ログが base64 でエンコードされた gzip アーカイブとして障害用の設定マップに追加されます。この場合は、上記のコマンドの出力を base64 --decode | gunzip にパイプ処理する必要があります。圧縮されたログの有無は、設定マップにある file-integrity.openshift.io/compressed アノテーションキーで示唆されます。

6.6.6. イベントについて

FileIntegrity および FileIntegrityNodeStatus オブジェクトのステータスの移行は イベント でログに記録されます。イベントの作成時間は、Initializing から Active など、最新の移行を反映し、必ずしも最新のスキャン結果ではありません。ただし、最新のイベントは常に最新のステータスを反映しています。

$ oc get events --field-selector reason=FileIntegrityStatus

出力例

LAST SEEN   TYPE     REASON                OBJECT                                MESSAGE
97s         Normal   FileIntegrityStatus   fileintegrity/example-fileintegrity   Pending
67s         Normal   FileIntegrityStatus   fileintegrity/example-fileintegrity   Initializing
37s         Normal   FileIntegrityStatus   fileintegrity/example-fileintegrity   Active

ノードのスキャンに失敗すると、イベントは add/changed/removed および設定マップ情報と共に作成されます。

$ oc get events --field-selector reason=NodeIntegrityStatus

出力例

LAST SEEN   TYPE      REASON                OBJECT                                MESSAGE
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-134-173.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-168-238.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-169-175.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-152-92.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-158-144.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-131-30.ec2.internal
87m         Warning   NodeIntegrityStatus   fileintegrity/example-fileintegrity   node ip-10-0-152-92.ec2.internal has changed! a:1,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed

ノードのステータスが移行されなかった場合でも、追加、変更、または削除されたファイルの数を変更すると、新しいイベントが生成されます。

$ oc get events --field-selector reason=NodeIntegrityStatus

出力例

LAST SEEN   TYPE      REASON                OBJECT                                MESSAGE
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-134-173.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-168-238.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-169-175.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-152-92.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-158-144.ec2.internal
114m        Normal    NodeIntegrityStatus   fileintegrity/example-fileintegrity   no changes to node ip-10-0-131-30.ec2.internal
87m         Warning   NodeIntegrityStatus   fileintegrity/example-fileintegrity   node ip-10-0-152-92.ec2.internal has changed! a:1,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed
40m         Warning   NodeIntegrityStatus   fileintegrity/example-fileintegrity   node ip-10-0-152-92.ec2.internal has changed! a:3,c:1,r:0 \ log:openshift-file-integrity/aide-ds-example-fileintegrity-ip-10-0-152-92.ec2.internal-failed

6.6. File Integrity Operator について

6.6.1. FileIntegrity カスタムリソースの作成

6.6.2. FileIntegrity カスタムリソースのステータスの確認

6.6.3. FileIntegrity カスタムリソースの各種フェーズ

6.6.4. FileIntegrityNodeStatuses オブジェクトについて

6.6.5. FileIntegrityNodeStatus CR ステータスタイプ

6.6.5.1. FileIntegrityNodeStatus CR の成功例

6.6.5.2. FileIntegrityNodeStatus CR の失敗ステータスの例

6.6.6. イベントについて

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links