Kubernetes監査イベント
Falco v0.13.0では、サポートされているイベントソースのリストにKubernetes監査イベントが追加されています。これは、システムコールイベントの既存のサポートに追加されます。監査イベントの改善された実装がKubernetes v1.11で導入され、kube-apiserverへのリクエストとレスポンスのログを提供します。ほとんどすべてのクラスター管理タスクはAPIサーバーを介して実行されるため、監査ログはクラスターに加えられた変更を効果的に追跡できます。
この例は次のとおりです:
- ポッド、サービス、デプロイメント、デーモンセットなどの作成と破棄。
- ConfigMapまたはシークレットの作成、更新、削除
- エンドポイントに導入された変更をサブスクライブする
これらのシナリオをカバーするために、次のような注目すべきまたは疑わしいアクティビティを監視するFalcoルールのセットが追加されました:
- 特権付きのポッドの作成、機密ホストパスのマウント、またはホストネットワークの使用。
cluster-admin
などの過度に広い権限をユーザーに付与する。- 機密情報を含むConfigMapの作成。
クラスターに監査ログが設定され、イベントがFalcoに送信されるように選択されたら、これらのイベントを読み取り、疑わしいアクティビティやその他の注目すべきアクティビティの通知を送信できるFalcoルールを作成できます。
Falcoの新機能
Falcoの全体的なアーキテクチャーは同じままで、イベントは一連のルールと照合され、ルールは疑わしいビヘイビアまたは注目すべきビヘイビアを識別します。Falcoがv0.13.0で導入するのは、1つだけではなく、別々に読み取られ、ルールのセットに対して個別に照合される2つの並列の独立したイベントストリームです。
Kubernetes監査イベントを受信するために、Falcoは設定可能なポートでリッスンし、設定可能なエンドポイントでPOSTリクエストを受け入れるcivetwebWebサーバーを埋め込みます。組み込みWebサーバーの構成については、設定のページ を参照してください。 ポストされたJSONオブジェクトはイベントを含みます。
特定のルールは、source
属性を介して、システムコールイベントまたはKubernetes監査イベントに関連付けられます。指定しない場合、ソースはデフォルトでsyscall
になります。 ソースがsyscall
のルールは、システムコールイベントと照合されます。ソースが k8s_audit
のルールは、Kubernetes監査イベントと照合されます。
Falcoの使用を開始するには、Falcoによる監査 を参照してください。
条件とフィールド
システムコールルールと同様に、Kubernetes監査ルールの条件フィールドは、演算子とイベントフィールドに基づく論理式です。 たとえば、ka.user.name
です。 特定のイベントフィールドは、jsonオブジェクトから1つのプロパティ値を選択します。たとえば、フィールドka.user.name
は最初にKubernetes監査イベント内のuser
オブジェクトを識別し、そのオブジェクトのusername
プロパティを選択します。
Falcoには、Kubernetes event/jsonオブジェクトの共通プロパティにアクセスする多数の事前定義フィールドが含まれています。falco --list k8s_audit
を使用してフィールドを表示できます。
事前定義されたフィールドのいずれかでカバーされていないKubernetes監査 event/jsonオブジェクトのプロパティ値を選択するには、jevt.value[<json pointer>]
が使用できます。 JSONポインターを使用して、jsonオブジェクトから単一のプロパティ値を選択します。これにより、Kubernetes監査イベントから任意のプロパティ値を選択して、ルールの条件を作成できます。たとえば、ka.username
を抽出する同等の方法は、jevt.value[/user/username]
です。
Kubernetes監査ルール
Kubernetes監査イベント専用のルールは、k8s_audit_rules.yamlに記載されています。 デーモンとしてインストールされると、falcoはこのルールファイルを/etc/falco/
にインストールし、使用できるようにします。
例
k8s_audit_rules.yaml
のルールの1つは次のとおりです:
Configmap contains private credentials
ルールは、AWSキーやパスワードなどの機密アイテムで作成されたConfigMapをチェックします。
このような場合のルールの動作を見てみましょう。このトピックでは、Kubernetes監査ロギングが環境で設定されていることを前提としています。 AWS認証情報を含むConfigMapを作成します:
このConfigMapを作成すると、監査ログに次のjsonオブジェクトが生成されます:
ConfigMapにプライベート資格情報が含まれている場合、ルールは以下のフィールドを指定された順序で使用します:
kevt
:オブジェクトのstage
プロパティがk8s_audit_stages
リストに存在するかどうかを確認します。configmap
:objectRef > resource
プロパティの値が"configmap"に等しいかどうかを確認します。modify
:verb
の値が次のいずれかであるかどうかを確認します:create
,update
,patch
。contains-private-credentials
:requestObject > data
でConfigMapのコンテンツを検索し、contains_private_credentials
マクロで指定された機密性の高い文字列を探します。
もしそうなら、Falcoイベントが生成されます:
The output string is used to print essential information about the audit event, including: 出力文字列は、監査イベントに関する次のような重要な情報を出力するために使用されます:
- user:
%ka.user.name
- verb:
%ka.verb
- ConfigMap name:
%ka.req.configmap.name
- ConfigMap contents:
%ka.req.configmap.obj
Kubernetes監査ログを有効にする
Kubernetes監査ログを有効にするには、kube-apiserver
プロセスの引数を変更して、--audit-policy-file
および --audit-webhook-config
引数を追加し、audit policy/webhookを実装するファイルを提供する必要があります。これを行う方法の詳細な説明を提供することはFalcoのドキュメントの範囲外ですが、サンプルファイル 監査ログをminikubeに追加する方法を示します。
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.