今日覚えて帰ること
監査ログの設定方法
- 監査ポリシー用のファイルを作成する
- kube-apiserverフラグを更新する
- ボリュームをマウントする
Auditing Enable Audit Logging
Enable Audit Logging for giving Audit Policy
Configure the Apiserver for Audit Logging.
The log path should be
/etc/kubernetes/audit-logs/audit.logon the host and inside the container.The existing Audit Policy to use is at
/etc/kubernetes/audit-policy/policy.yaml. The path should be the same on the host and inside the container.Set argument
--audit-log-maxsize=7Set argument
--audit-log-maxbackup=2
監査ログを取るようApiserverを設定せよ、という問題ですね。
以下が参考になります。
kube-apiserverがpodとして動いている場合は、
- 監査ポリシー用のファイルを作成する
- kube-apiserverフラグを更新する
- ボリュームをマウントする
必要があります。
今回はポリシーはすでに存在するので他二つを実施します。
kube-apiserverフラグを更新する
ログファイルの保存先となるディレクトリを作成します。
mkdir /etc/kubernetes/audit-logs
以下のように /etc/kubernetes/manifests/kube-apiserver.yaml を修正します。
# enable Audit Logs
spec:
containers:
- command:
- kube-apiserver
- --audit-policy-file=/etc/kubernetes/audit-policy/policy.yaml
- --audit-log-path=/etc/kubernetes/audit-logs/audit.log
- --audit-log-maxsize=7
- --audit-log-maxbackup=2ボリュームをマウントする
そのまま続けて /etc/kubernetes/manifests/kube-apiserver.yaml を修正します。
hostPathとコンテナ上のパスが一致する必要があります。
# add new Volumes
volumes:
- name: audit-policy
hostPath:
path: /etc/kubernetes/audit-policy/policy.yaml
type: File
- name: audit-logs
hostPath:
path: /etc/kubernetes/audit-logs
type: DirectoryOrCreate# add new VolumeMounts
volumeMounts:
- mountPath: /etc/kubernetes/audit-policy/policy.yaml
name: audit-policy
readOnly: true
- mountPath: /etc/kubernetes/audit-logs
name: audit-logs
readOnly: falseあまり言うことはないですね。
公式に書いている通りにやればOKです。
強いて言うならpolicyのファイルってボリュームとしてマウントするんだなあ、と思いました。
kube-apiserverが再起動したあと、以下のコマンドでログが生成されていることを確認できれば完璧です。
controlplane $ stat /etc/kubernetes/audit-logs/audit.log
File: /etc/kubernetes/audit-logs/audit.log
Size: 1782694 Blocks: 3488 IO Block: 4096 regular file
Device: fc01h/64513d Inode: 1326280 Links: 1
Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2024-07-30 14:08:08.123684769 +0000
Modify: 2024-07-30 14:25:45.608442070 +0000
Change: 2024-07-30 14:25:45.608442070 +0000
Birth: -policyの書き方
合格体験記によると、どうやらpolicyを自分で修正できるようになる必要がありそうです。
（さすがに1から作る必要はないと思う。）
公式から一部引用します。
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# Log pod changes at RequestResponse level
- level: RequestResponse
resources:
- group: ""
# Resource "pods" doesn't match requests to any subresource of pods,
# which is consistent with the RBAC policy.
resources: ["pods"]
# Log "pods/log", "pods/status" at Metadata level
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"]
# Don't log requests to a configmap called "controller-leader"
- level: None
resources:
- group: ""
resources: ["configmaps"]
resourceNames: ["controller-leader"]
ruleは必須フィールドで、これがなければpolicyとして扱ってもらえない。
絶対に書こう。
ルールは上から順に評価され、合致した時点でそのルールに記載されている処理が行われる。
例えば以下のルールでは secrets のログは level: Metadata として扱われる。
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# log Secret resources audits, level Metadata
- level: Metadata
resources:
- group: ""
resources: ["secrets"]
# log node related audits, level RequestResponse
- level: None
resources:
- group: ""
resources: ["secrets"]levelの違いはこちら↓
- None : このルールに一致する監査ログを出力しない。
- Metadata : リクエストのメタデータ（リクエストしているユーザー、タイムスタンプ、リソース、操作など）を出力するが、リクエストやレスポンスの本文は出力しない。
- Request : リクエストのメタデータと本文を出力するが、レスポンス内容は出力しない。これは、リソース以外に対するリクエストには適用されないとのこと。
- RequestResponse : リクエストのメタデータ、レスポンス含めた本文を出力する。上記と同じくリソース以外に対するリクエストには適用されないとのこと。
また、リソースによってgroupの値が違うことに注意。
特に deployments や statefulsetsは group が app であることに要注意。
ただgroupって必須フィールドじゃなさそうなのでそもそもフィールドを記載しなくてもいい気がするが……
参考
