Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2021年2月9日に Pawan Shankar が投稿したブログ (https://sysdig.com/blog/kubernetes-audit-log-falco/) を元に日本語に翻訳・再構成した内容となっております。
Kubernetesの採用が拡大し続ける中、Kubernetesのセキュリティ戦略に監査ログを組み込むことは、クラスター内で発生しているすべてのイベントを完全に可視化するために重要です。
Kubernetes監査ログ機能は Kubernetes 1.11 で導入されました。新しいデプロイメントの作成、ネームスペースの削除、ノードポートサービスの開始などのイベントをキャプチャし、セキュリティを確保する上で重要な役割を果たします。
この記事では、Kubernetes監査ログの仕組みと、オープンソースのランタイムセキュリティツール Falco と統合してクラスターの不審なアクティビティを検出する方法を紹介します。
Kubernetesの監査ログのメリット
Kubernetes の監査ログを統合することで、以下の質問に答えることができます。
- 何が起こったのか？どの新しいポッドが作成されたのか？
- 誰がやったのか？ユーザー、グループ、またはサービスアカウント
- それはいつ発生したのか？イベントのタイムスタンプ
- どこで発生したか？ポッドが作成されたネームスペース
攻撃者や誤操作による変更も監査ログに残り、セキュリティツールがそれを解析して警告を発することができます。
- RequestReceived: リクエストを受信した時点でイベントが生成されます。
- ResponseStarted: レスポンスヘッダー送信時にイベントが生成されます。
- ResponseComplete: レスポンス送信完了時にイベントが生成されます。
- Panic: パニック発生時にイベントが生成されます。
Kubernetesの監査ポリシーの例
監査ポリシーを使うと、クラスター内のすべてのアクティビティから必要なものだけを記録できます。重要なコンポーネント（ポッド、シークレット、設定など）に関連するリクエストをフィルタリングします。
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
- "RequestReceived"
rules:
- level: RequestResponse
resources:
- group: ""
resources: ["pods"]
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"]
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: ""
resources: ["endpoints", "services"]
- level: None
userGroups: ["system:authenticated"]
nonResourceURLs:
- "/api*"
- "/version"
- level: Request
resources:
- group: ""
resources: ["configmaps"]
namespaces: ["kube-system"]
- level: Metadata
resources:
- group: ""
resources: ["secrets", "configmaps"]
- level: Metadata
omitStages:
- "RequestReceived"
このポリシーを適用するには、kube-apiserver 起動時に --audit-policy-file フラグを使用します。ポリシーには複数のルールを定義でき、それぞれイベントの監査レベルを指定します。
- None: イベントを記録しない
- Metadata: メタデータのみを記録
- Request: メタデータとリクエストボディを記録
- RequestResponse: メタデータ、リクエスト、レスポンスボディを記録
Falcoを監査バックエンドとして設定
ログを保存するだけでは、脅威に即時対応できません。Falco のようなセキュリティツールと統合することで、監査ログの潜在能力を最大限に引き出せます。
- ログバックエンド: ファイルとして出力。ツールが直接解析可能。
- Webhookバックエンド: イベントを外部HTTP APIに送信。
以下は、Webhookバックエンドを使って Falco にイベントを送信する例です。
apiVersion: v1
kind: Config
clusters:
- name: falco
cluster:
server: http://$FALCO_SERVICE_CLUSTERIP:8765/k8s_audit
contexts:
- context:
cluster: falco
user: ""
name: default-context
current-context: default-context
preferences: {}
users: []
server フィールドは、監査イベント送信先のリモートエンドポイントを定義します。
Webhookを有効にするには、--audit-webhook-config-file フラグを設定します。Kubernetes 1.13〜1.18 では AuditSink オブジェクトを使った 動的Webhook設定 が可能でしたが、1.19で削除 されました。
End-to-Endの例
以下の例は、ConfigMapを作成して Falco にイベントをトリガーする方法です。
apiVersion: v1
data:
ui.properties: |
color.good=purple
color.bad=yellow
allow.textmode=true
access.properties: |
aws_access_key_id = MY-ID
aws_secret_access_key = MY-KEY
kind: ConfigMap
metadata:
name: my-config
namespace: default
> kubectl create -f badconfigmap.yaml
これにより、Falco のルール Create/Modify Configmap With Private Credentials がトリガーされます。
- rule: Create/Modify Configmap With Private Credentials
desc: Detect creating/modifying a configmap containing a private credential
condition: kevt and configmap and kmodify and contains_private_credentials
output: K8s configmap with private credential (user=%ka.user.name verb=%ka.verb configmap=%ka.req.configmap.name)
priority: WARNING
source: k8s_audit
tags: [k8s]
> kubectl tail -f falco-b4ck9
Warning Kubernetes configmap with private credential
(user=minikube-user verb=create configmap=my-config config={...})
まとめ
Kubernetesのセキュリティを強化するには、監査ログイベントのような不審な動作を可視化し、継続的にモニタリングすることが重要です。
ルールをチューニングし、冗長性を抑えることでログコストを削減できますが、最も重要なのは脅威検知エンジンとして Falco を使用することです。
Sysdig Secure では、Falco のルールを拡張し、Kubernetes セキュリティ管理をさらに簡単にします。30日間の無料トライアル をぜひお試しください。