概要
Kubernetes 監査ログを収集すると、任意のサービスで作成される Kubernetes API へのあらゆる呼び出しをはじめ、Kubernetes クラスター内で起こるすべてのことを追跡できます。たとえば、Control Plane(ビルトインコントローラ、スケジューラ)、ノードのデーモン(kubelet、kube-proxy、その他)、クラスターサービス(クラスターのオートスケーラーなど)、ユーザーが作成する kubectl
リクエスト、さらに Kubernetes API 自体も追跡できます。
Kubernetes 監査ログインテグレーションを使用すると、アクセス許可の問題を診断したり、更新すべき RBAC ポリシーを特定したり、クラスター全体に影響を与えるほどレスポンスの遅い API リクエストを追跡したりできます。これらのトピックについて詳しくは、KubeCon 2019 での Datadog による講演を参照してください。
セットアップ
このインテグレーションは Agent 6.0 以上で使用可能です。
コンフィギュレーション
Kubernetes 監査ログの設定について詳しくは、Kubernetes Auditing を参照してください。
Kubernetes で監査ログを有効にするには
Kubernetes の監査ログはデフォルトで無効になっています。監査ログを API サーバーコンフィギュレーションで有効にするには、監査ポリシーファイルのパスを以下のように指定します。
kube-apiserver
[...]
--audit-log-path=/var/log/kubernetes/apiserver/audit.log
--audit-policy-file=/etc/kubernetes/audit-policies/policy.yaml
ポリシーファイルを /etc/kubernetes/audit-policies/policy.yaml
に作成し、監査ログに取得する API リクエストのタイプを指定します。監査ポリシー規則は上から順に評価されます。API サーバーは操作やリソースのタイプ別に規則を探し、一致する最初の規則に従います。監査ポリシーの例を以下に示します。
# /etc/kubernetes/audit-policies/policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# 以下のリクエストのログは作成しない
- level: None
nonResourceURLs:
- '/healthz*'
- '/logs'
- '/metrics'
- '/swagger*'
- '/version'
# 仕様やステータスにトークンを含めないようにレベルを Metadata に制限する
- level: Metadata
omitStages:
- RequestReceived
resources:
- group: authentication.k8s.io
resources:
- tokenreviews
# 認証委任の監査を拡張
- level: RequestResponse
omitStages:
- RequestReceived
resources:
- group: authorization.k8s.io
resources:
- subjectaccessreviews
# ポッド変更のログを RequestResponse レベルで作成
- level: RequestResponse
omitStages:
- RequestReceived
resources:
# コア API グループ; 必要に応じてサードパーティまたは自作の API サービスを追加
- group: ''
resources: ['pods']
verbs: ['create', 'patch', 'update', 'delete']
# その他すべてのログを Metadata レベルで作成
- level: Metadata
omitStages:
- RequestReceived
このポリシーの例では、特定のタイプの操作(更新、パッチ、作成、削除)によってクラスターが変更された場合に、最高レベルの詳細なログが API サーバーによって作成されます。また、subjectaccessreviews
リソースへのリクエストも最高レベルで追跡され、認証委任の問題を解決するために役立てることができます。
機密性の高いデータ(tokenreviews
リソースなど)を含むエンドポイントに対しては、ログの詳細レベルを Metadata
まで下げることをお勧めします。これにより、RequestReceived
のステージもログから省略されます。
最後のセクションでは、先行する規則で明示されていないすべてのことに対し、Metadata
レベルでログを作成するようにポリシーが構成されます。監査ログがあまりに詳細な場合は、重要度の低いアクションや動詞(list、watch、get などクラスターの状態が変化しない操作)を除外することもできます。
ログの収集
Kubernetes 環境に Agent をインストールします。
ログの収集はデフォルトで無効になっています。DaemonSet の env
セクションでこれを有効にします。
env:
# (...)
- name: DD_LOGS_ENABLED
value: 'true'
監査ログのディレクトリと、Agent が使用するディレクトリをマウントし、ポインタを格納して、最後に送信されたログをそのファイルから特定できるようにします。それには、daemonset の volumeMounts
セクションに以下を追加します。
# (...)
volumeMounts:
# (...)
- name: pointdir
mountPath: /opt/datadog-agent/run
- name: auditdir
mountPath: /var/log/kubernetes/apiserver
- name: dd-agent-config
mountPath: /conf.d/kubernetes_audit.d
# (...)
volumes:
# (...)
- hostPath:
path: /opt/datadog-agent/run
name: pointdir
- hostPath:
path: /var/log/kubernetes/apiserver
name: auditdir
- name: dd-agent-config
configMap:
name: dd-agent-config
items:
- key: kubernetes-audit-log
path: conf.yaml
# (...)
これにより、Agent が監査ログファイルからログを収集するよう構成するための conf.d
フォルダもマウントされます。
ConfigMap を使用し、そのファイルからログを収集するように Agent を構成します。
kind: ConfigMap
apiVersion: v1
metadata:
name: dd-agent-config
namespace: default
data:
kubernetes-audit-log: |-
logs:
- type: file
path: /var/log/kubernetes/apiserver/audit.log
source: kubernetes.audit
service: audit
検証
Agent の status サブコマンドを実行し、Checks セクションで Logs
を探します。
トラブルシューティング
ご不明な点は、Datadog のサポートチームまでお問合せください。
その他の参考資料