CNDT2019_Kubernetes_audit_log

D1b28ca276bee52e56ba11785f70d2d6?s=47 makocchi
July 23, 2019

 CNDT2019_Kubernetes_audit_log

CloudNative Days 2019 / OpenStack Days 2019 の発表資料です
「Kubernetes に Audit log を求めるのは間違っているだろうか?」

D1b28ca276bee52e56ba11785f70d2d6?s=128

makocchi

July 23, 2019
Tweet

Transcript

  1. 1.

    CloudNative Days Tokyo 2019 Presented by @makocchi 1 CloudNative Days

    Tokyo 2019 Kubernetes に Audit log を求めるのは 間違っているのだろうか?
  2. 3.

    CloudNative Days Tokyo 2019 Presented by @makocchi 3 このセッションの Twitter

    のハッシュタグは #CNDT2019 #OSDT2019 #RoomH です! みんなどんどんお願いします!
  3. 4.

    Presented by @makocchi CloudNative Days Tokyo 2019 4 Makoto Hasegawa

    Working at // Adtech Division, CyberAgent, Inc Currently // Develop and maintain private OpenStack cloud. Develop and maintain Kubernetes as a Service platform. CKA (Certified Kubernetes Administrator) CKA-1700-0150-0100 CKAD (Certified Kubernetes Application Developper) CKAD-1800-0005-0100 Job Title // Technical Lead Infrastructure Engineer WHO am I Twitter // @makocchi Facebook // makocchi0923 Hobby // Playing bass
  4. 5.

    Presented by @makocchi CloudNative Days Tokyo 2019 5 Japan Container

    Days V18.12 「runc だけじゃないコンテナ low level runtime 徹底比較」 Japan Container Days V18.04 「Docker だけじゃないコンテナ runtime 徹底比較」 前回までの発表ももしよかったら見てくださいね!
  5. 6.
  6. 8.
  7. 9.

    CloudNative Days Tokyo 2019 Presented by @makocchi 9 Pod が吐き出すログ?

    各種 Component(apiserver, scheduler, etc)のログ?
  8. 10.

    CloudNative Days Tokyo 2019 Presented by @makocchi 10 Pod が吐き出すログ?

    各種 Component(apiserver, scheduler, etc)のログ?
  9. 11.

    CloudNative Days Tokyo 2019 Presented by @makocchi 11 Pod が吐き出すログ?

    各種 Component(apiserver, scheduler, etc)のログ? Audit log(監査ログ)です!
  10. 12.

    CloudNative Days Tokyo 2019 Presented by @makocchi 12 Pod が吐き出すログ

    各種 Component(apiserver, scheduler, etc)のログ こちらのセッションも合わせてどうぞ!
  11. 13.

    Presented by @makocchi CloudNative Days Tokyo 2019 13 TODAY’S AGENDA

    Self Introduction Let’s monitor audit log What is kubernetes audit log? Conclusion
  12. 15.

    Presented by @makocchi CloudNative Days Tokyo 2019 15 What is

    kubernetes audit log? kube-apiserver は元々監査の機能を持っています デフォルトでは有効になっていない (各種 Public Cloud では有効になっていることが多い) 監査ログをファイルに出力したり外部の Endpoint に対して Webhook する機能があります 監査ログを調べることで Cluster の管理者はこんなことが分かるようになります! WHAT : 何が起こったのか? WHEN : いつ起こったのか? WHO : 誰がやったのか? WHERE : どこから操作されたのか? WHAT : 何に対して行われたのか?
  13. 16.

    Presented by @makocchi CloudNative Days Tokyo 2019 16 What is

    kubernetes audit log? こんな時に監査ログ取っておくといいよね おやおや なんか API がエラー出すようになったんですけど あれ なんか configMap の中身が書き換わってますね・・・ 誰だよー わかりません・・\(^o^)/
  14. 18.

    Presented by @makocchi CloudNative Days Tokyo 2019 18 How to

    enable audit log? 監査ログを有効にする前に考えないといけないことが 2 つあります ポリシー バックエンド
  15. 19.

    Presented by @makocchi CloudNative Days Tokyo 2019 19 How to

    enable audit log? 監査ログを有効にする前に考えないといけないことが 2 つあります まずはポリシーから見ていきましょう ポリシー バックエンド
  16. 20.

    Presented by @makocchi CloudNative Days Tokyo 2019 20 How to

    enable audit log? 監査ログのポリシー (Audit Policy) どのログをどのレベルで出力するのか(しないのか)をポリシーで定義することができます ポリシー内では “どのレベル” (level) / “どのログ” (resources) 等をルールで定義します level と resources 等をセットにしたルール(rules)を複数記述していきます ちなみに yaml 形式 ポリシー バックエンド ポリシー rules level resources level resources …
  17. 21.

    Presented by @makocchi CloudNative Days Tokyo 2019 21 How to

    enable audit log? 監査ログのポリシー (Audit Policy) 実際にはこのような yaml になります ポリシー バックエンド apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" resources: ["endpoints", "services", "services/status"] - level: Request resources: - group: "" resources: ["configmaps"] namespaces: ["kube-system"] - level: Metadata omitStages: - “RequestReceived"
  18. 22.

    Presented by @makocchi CloudNative Days Tokyo 2019 22 How to

    enable audit log? 監査ログのポリシー (Audit Policy) 例えばここの記述は・・・ ポリシー バックエンド apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" resources: ["endpoints", "services", "services/status"] - level: Request resources: - group: "" resources: ["configmaps"] namespaces: ["kube-system"] - level: Metadata omitStages: - “RequestReceived" “system:kube-proxy” の認証情報(users)をもつ “endpoints” “services” “services/status” (resources)への “watch” リクエスト(verbs)を 無視する(None)
  19. 23.

    Presented by @makocchi CloudNative Days Tokyo 2019 23 How to

    enable audit log? 監査ログのポリシー (Audit Policy) さらにここの記述は・・・ ポリシー バックエンド “kube-system” の namespace にある “configmaps” (resources)への 全てのリクエストを “Request” レベルで出力する apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" resources: ["endpoints", "services", "services/status"] - level: Request resources: - group: "" resources: ["configmaps"] namespaces: ["kube-system"] - level: Metadata omitStages: - “RequestReceived"
  20. 24.

    Presented by @makocchi CloudNative Days Tokyo 2019 24 How to

    enable audit log? 監査ログのポリシー (Audit Policy) 4つのレベル ポリシー バックエンド “Level” に記述できるものは 4 種類あります それぞれで出力内容が異なります apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" resources: ["endpoints", "services", "services/status"] - level: Request resources: - group: "" resources: ["configmaps"] namespaces: ["kube-system"] - level: Metadata omitStages: - “RequestReceived" None : 出力しない Metadata : リクエストの user/timestamp/verbs 等を出力する Request : Metadata に加えてリクエストの Body を出力する RequestResponse : Request に加えてレスポンスの Body を出力する
  21. 25.

    Presented by @makocchi CloudNative Days Tokyo 2019 25 How to

    enable audit log? 監査ログのポリシー (Audit Policy) 監査ログを記録するステージ ポリシー バックエンド ステージという概念があってどのタイミングのログな のかを定義することができます この場合だと全ての “RequestReceived” の以外のタイ ミングのイベントは Metadata レベルで出力されるこ とになります apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: None users: ["system:kube-proxy"] verbs: ["watch"] resources: - group: "" resources: ["endpoints", "services", "services/status"] - level: Request resources: - group: "" resources: ["configmaps"] namespaces: ["kube-system"] - level: Metadata omitStages: - “RequestReceived"
  22. 26.

    Presented by @makocchi CloudNative Days Tokyo 2019 26 How to

    enable audit log? 監査ログのポリシー (Audit Policy) 監査ログステージ (Audit Stages) ポリシー バックエンド kube-apiserver RequestReceived Response Panic ResponseStarted ResponseComplete Request Response
  23. 27.

    Presented by @makocchi CloudNative Days Tokyo 2019 27 How to

    enable audit log? 監査ログのポリシー (Audit Policy) 監査ログステージ (Audit Stages) ポリシー バックエンド kube-apiserver RequestReceived Response Panic ResponseStarted ResponseComplete Request Response
  24. 28.

    Presented by @makocchi CloudNative Days Tokyo 2019 How to enable

    audit log? 監査ログのポリシー (Audit Policy) まとめ ログの出力条件は level / stage / resources / verbs 等の組み合わせで決定されます level は 4 種類 (None / Metadata / Request / RequestResponse) stage は 4 種類 (RequestReceived / ResponseStarted / ResponseComple / Panic) ポリシー バックエンド
  25. 29.

    Presented by @makocchi CloudNative Days Tokyo 2019 29 How to

    enable audit log? 監査ログを有効にする前に考えないといけないことが 2 つあります 続いてバックエンドに行きます ポリシー バックエンド
  26. 30.

    Presented by @makocchi CloudNative Days Tokyo 2019 30 How to

    enable audit log? 監査ログのバックエンド (Audit Backends) ログの出力先(バックエンド)に指定できるのは 2 つ ファイルとして出力する方式と Webhook で外部の Endpoint へ出力する方式 出力時に流量制限(Throttle)をすることができます(qps や size 等) Kubernetes 1.13 から alpha 機能で Webhook のバックエンドをダイナミックに変更できる ようになりました(Dynamic backend) 豆知識 : ログの出力には “lumberjack” の package が使用されています (gopkg.in/ natefinch/lumberjack.v2) ポリシー バックエンド
  27. 31.

    Presented by @makocchi CloudNative Days Tokyo 2019 31 How to

    enable audit log? さぁこの 2 つさえ決めてしまえばあとは設定するだけです! ポリシー バックエンド \決まったぞ!/ \決まったぞ!/
  28. 32.

    Presented by @makocchi CloudNative Days Tokyo 2019 32 How to

    enable audit log? ポリシーファイルの指定 kube-apiserver に “--audit-policy-file" オプションを設定します ex) --audit-policy-file=/etc/kubernetes/audit-policy.yaml audit-policy.yaml を書くのがメンドクサイあなた!(自分もです) お手本を参考にカスタマイズしましょう! お手本その1 (kubernetes.io/docs/ のサンプル) https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/audit/audit-policy.yaml お手本その2 (github.com/kubernetes/kubernetes の gce のサンプル) https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/gce/gci/configure-helper.sh
  29. 33.

    Presented by @makocchi CloudNative Days Tokyo 2019 33 How to

    enable audit log? バックエンドの指定 (ファイル) ファイル出力の場合は "--audit-log-path" オプションを設定します ex) --audit-log-path=/var/log/kube-apiserver/audit.log --audit-log-path に指定されたファイルは自動的に rotation されます その際には audit-2019-07-19T03-10-44.452.log のように rotate されます rotate に関するオプションも用意されていますので、適宜設定してください --audit-log-maxage 何日間保存するか (デフォルトは 0 つまり無期限) --audit-log-maxbackup 何世代保存するか (デフォルトは 0 つまり無期限) --audit-log-maxsize このサイズを超えたら rotate (デフォルト 100MB) ちゃんと設定すべし
  30. 34.

    Presented by @makocchi CloudNative Days Tokyo 2019 34 How to

    enable audit log? バックエンドの指定 (Webhook) Webhook の場合は "--audit-webhook-config-file" オプションを設定します ex) --audit-webhook-config-file=/etc/kubernetes/audit-webhook.yaml webhookに渡す config はいわゆる kubeconfig Dynamic backendを有効にする場合は --audit-dynamic-configuration --feature-gates=DynamicAuditing=true --runtime-config=auditregistration.k8s.io/v1alpha1=true の設定が別途必要になります apiVersion: v1 kind: Config clusters: - cluster: insecure-skip-tls-verify: true server: https://127.0.0.1:1234/webhook name: webhook contexts: - context: cluster: webhook user: webhook name: webhook current-context: webhook users: - name: webhook
  31. 36.

    Presented by @makocchi CloudNative Days Tokyo 2019 36 Actual audit

    log { "kind": "Event", "apiVersion": "audit.k8s.io/v1", "level": "Request", "auditID": "bebead89-a12b-4152-8ede-4bed98ebf745", "stage": "ResponseComplete", "requestURI": "/api/v1/namespaces/default/pods/nginx", "verb": "get", "user": { "username": "demo", "uid": "10a14d993b164b34b3aea325f9a599f5", "groups": [ "2ad03dfcd93b46a18f2bb081057753ab", "system:authenticated" ], }, "sourceIPs": [ "1.2.3.4" ], "userAgent": "kubectl/v1.15.0 (linux/amd64) kubernetes/e8462b5", "objectRef": { "resource": "pods", "namespace": "default", "name": "nginx", "apiVersion": "v1" }, "responseStatus": { "metadata": {}, "code": 200 }, "requestReceivedTimestamp": "2019-07-19T05:01:55.156727Z", "stageTimestamp": "2019-07-19T05:01:55.158597Z", "annotations": { "authorization.k8s.io/decision": "allow", "authorization.k8s.io/reason": "" } } とある pod を get した時の audit log (見やすいように整形してあります)
  32. 37.

    Presented by @makocchi CloudNative Days Tokyo 2019 { "kind": "Event",

    "apiVersion": "audit.k8s.io/v1", "level": "Request", "auditID": "bebead89-a12b-4152-8ede-4bed98ebf745", "stage": "ResponseComplete", "requestURI": "/api/v1/namespaces/default/pods/nginx", "verb": "get", "user": { "username": "demo", "uid": "10a14d993b164b34b3aea325f9a599f5", "groups": [ "2ad03dfcd93b46a18f2bb081057753ab", "system:authenticated" ], }, "sourceIPs": [ "1.2.3.4" ], "userAgent": "kubectl/v1.15.0 (linux/amd64) kubernetes/e8462b5", "objectRef": { "resource": "pods", "namespace": "default", "name": "nginx", "apiVersion": "v1" }, "responseStatus": { "metadata": {}, "code": 200 }, "requestReceivedTimestamp": "2019-07-19T05:01:55.156727Z", "stageTimestamp": "2019-07-19T05:01:55.158597Z", "annotations": { "authorization.k8s.io/decision": "allow", "authorization.k8s.io/reason": "" } } 37 Actual audit log いっぱい出るから書ききれない
  33. 38.

    Presented by @makocchi CloudNative Days Tokyo 2019 { "kind": "Event",

    "apiVersion": "audit.k8s.io/v1", "level": "Request", "auditID": "bebead89-a12b-4152-8ede-4bed98ebf745", "stage": "ResponseComplete", "requestURI": "/api/v1/namespaces/default/pods/nginx", "verb": "get", "user": { "username": "demo", "uid": "10a14d993b164b34b3aea325f9a599f5", "groups": [ "2ad03dfcd93b46a18f2bb081057753ab", "system:authenticated" ], }, "sourceIPs": [ "1.2.3.4" ], "userAgent": "kubectl/v1.15.0 (linux/amd64) kubernetes/e8462b5", "objectRef": { "resource": "pods", "namespace": "default", "name": "nginx", "apiVersion": "v1" }, "responseStatus": { "metadata": {}, "code": 200 }, "requestReceivedTimestamp": "2019-07-19T05:01:55.156727Z", "stageTimestamp": "2019-07-19T05:01:55.158597Z", "annotations": { "authorization.k8s.io/decision": "allow", "authorization.k8s.io/reason": "" } } 38 Actual audit log 細かくして説明していきます
  34. 39.

    Presented by @makocchi CloudNative Days Tokyo 2019 { "verb": "get",

    } 39 Actual audit log WHAT : 何が起こったのか? WHEN : いつ起こったのか? WHO : 誰がやったのか? WHERE : どこから操作されたのか? WHAT : 何に対して行われたのか?
  35. 40.

    Presented by @makocchi CloudNative Days Tokyo 2019 { "stage": "ResponseComplete",

    "stageTimestamp": "2019-07-19T05:01:55.158597Z", "requestReceivedTimestamp": "2019-07-19T05:01:55.156727Z", } 40 Actual audit log WHAT : 何が起こったのか? WHEN : いつ起こったのか? WHO : 誰がやったのか? WHERE : どこから操作されたのか? WHAT : 何に対して行われたのか?
  36. 41.

    Presented by @makocchi CloudNative Days Tokyo 2019 { "userAgent": "kubectl/v1.15.0

    (linux/amd64) kubernetes/e8462b5", "user": { "username": "demo", "uid": "10a14d993b164b34b3aea325f9a599f5", "groups": [ "2ad03dfcd93b46a18f2bb081057753ab", "system:authenticated" ], } } 41 Actual audit log WHAT : 何が起こったのか? WHEN : いつ起こったのか? WHO : 誰がやったのか? WHERE : どこから操作されたのか? WHAT : 何に対して行われたのか? uid と groups id がありますがこれは keystone と連携させている為
  37. 42.

    Presented by @makocchi CloudNative Days Tokyo 2019 { "sourceIPs": [

    "1.2.3.4" ], } 42 Actual audit log WHAT : 何が起こったのか? WHEN : いつ起こったのか? WHO : 誰がやったのか? WHERE : どこから操作されたのか? WHAT : 何に対して行われたのか?
  38. 43.

    Presented by @makocchi CloudNative Days Tokyo 2019 { "objectRef": {

    "resource": "pods", "namespace": "default", "name": "nginx", "apiVersion": "v1" }, } 43 Actual audit log WHAT : 何が起こったのか? WHEN : いつ起こったのか? WHO : 誰がやったのか? WHERE : どこから操作されたのか? WHAT : 何に対して行われたのか?
  39. 44.

    Presented by @makocchi CloudNative Days Tokyo 2019 { "responseStatus": {

    "metadata": {}, "code": 200 }, } 44 Actual audit log WHAT : 何が起こったのか? WHEN : いつ起こったのか? WHO : 誰がやったのか? WHERE : どこから操作されたのか? WHAT : 何に対して行われたのか? 最終的にどう返したのか
  40. 46.

    Presented by @makocchi CloudNative Days Tokyo 2019 46 What is

    the difference between normal log and audit log 普通のログ is... Jul 19 17:46:57 node1 kube-apiserver[27842]: I0719 17:46:57.810274 27842 wrap.go:47] GET /api/v1/ namespaces/default/pods/nginx: (44.037419ms) 200 [kubectl/v1.15.0 (linux/amd64) kubernetes/e8462b5 1.2.3.4:46512] 監査ログとの違いは... 設定が細かくできない(--v で level を変えるくらいしかできない) 監査ログには必要のないログも混ざって出てくる ほんとに監査するならば情報が足りない (stage / userとか) parse するのしんどい
  41. 48.

    Presented by @makocchi CloudNative Days Tokyo 2019 48 Let's monitor

    audit log - Design Pattern - audit log を出せることは分かった でもただ出すだけでいいんでしょうか
  42. 49.

    Presented by @makocchi CloudNative Days Tokyo 2019 49 Let's monitor

    audit log - Design Pattern - せっかくなのでちゃんと分析できるようにしたいですよね? したい!
  43. 50.

    Presented by @makocchi CloudNative Days Tokyo 2019 50 Pattern 1

    : audit file log + fluentd Let's monitor audit log - Design Pattern -
  44. 51.

    Presented by @makocchi CloudNative Days Tokyo 2019 51 Let's monitor

    audit log - Design Pattern - 監査ログをファイルに出力する場合は fluentd を使って集約しましょう Pattern 1 : audit file log + fluentd fluentd から先は何でも OK Elasticsearch + Kibana でもいいしオブ ジェクトストレージに格納して分析しても いいでしょう
  45. 52.

    Presented by @makocchi CloudNative Days Tokyo 2019 52 Let's monitor

    audit log - Design Pattern - Multi Masterの環境では fluentbit とかも使ってみるといいかもしれませんね Pattern 1 : audit file log + fluentd
  46. 53.

    Presented by @makocchi CloudNative Days Tokyo 2019 53 Let's monitor

    audit log - Design Pattern - Multi Masterの環境では fluentbit とかも使ってみるといいかもしれませんね Pattern 1 : audit file log + loki 試していないけども Grafana loki で 可視化することも可能かもしれません!
  47. 54.

    Presented by @makocchi CloudNative Days Tokyo 2019 54 Pattern 2

    : audit webhook log + logstash Let's monitor audit log - Design Pattern -
  48. 55.

    Presented by @makocchi CloudNative Days Tokyo 2019 55 Let's monitor

    audit log - Design Pattern - webhook の先を logstash にすることで様々な場所に格納できるようになります Pattern 2 : audit webhook log + logstash webhook
  49. 56.

    Presented by @makocchi CloudNative Days Tokyo 2019 56 Pattern 3

    : audit webhook log + falco Let's monitor audit log - Design Pattern - オススメ!
  50. 57.

    Presented by @makocchi CloudNative Days Tokyo 2019 57 Let's monitor

    audit log - Design Pattern - 分析まですることは無いんだけども、何かあった時に通知してほしい。 そんなユースケースの場合は falco を使うことをオススメします。 webhook の先を falco にして、特定のイベントが発生した際に slack に通知しましょう Pattern 3 : audit webhook log + falco webhook
  51. 58.

    Presented by @makocchi CloudNative Days Tokyo 2019 58 Container Native

    Runtime Security コンテナ環境のセキュリティをモニタリングしてくれるソフトウェア OSS で CNCF の sanbox プロジェクトになっています 主に開発しているのは sysdig 注意する点としては、モニタリングをするだけで実際に処理をブロック したりすることはしません What is falco? Let's monitor audit log - Design Pattern - Pattern 3 : audit webhook log + falco
  52. 59.

    Presented by @makocchi CloudNative Days Tokyo 2019 59 Let's monitor

    audit log - Design Pattern - Pattern 3 : audit webhook log + falco webhook たとえばこんな風に通知してくれます 便利! 今回は slack の通知で紹介しましたが slack だけではなくて様々な場所に 通知することができます
  53. 60.

    Presented by @makocchi CloudNative Days Tokyo 2019 60 Extra Pattern

    : audit file log + audit2rbac Let's monitor audit log - Design Pattern - https://github.com/liggitt/audit2rbac
  54. 61.

    Presented by @makocchi CloudNative Days Tokyo 2019 61 監査ログを分析して足りなかった RBAC

    の定義を作ってくれ るツール 例えば新しいアプリケーションを動かす時に、どんな RBAC が必要になるか分からない時や、適切な権限を持っているか 確認したい時に役立つかもしれません What is audit2rbac? Let's monitor audit log - Design Pattern - Extra Pattern : audit file log + audit2rbac https://github.com/liggitt/audit2rbac
  55. 62.

    Presented by @makocchi CloudNative Days Tokyo 2019 62 さっきの話もこうなるね! わかりません・・\(^o^)/

    Let's monitor audit log - Design Pattern - 監査ログをみてみよう・・・ 確かに開発チーム側から更新されたみたいだね 問い合わせてみて 聞いてみたら手元の環境に適用したと思っていたら サーバー側に適用されちゃってたみたいでした! kubectl の context 間違いだね よくあることだから対策案をしっかり話しておこう 誰だよー
  56. 64.

    Presented by @makocchi CloudNative Days Tokyo 2019 64 Conclusion Kubernetes

    の apiserver には監査ログを出す機能があります 監査ログはファイル形式と Webhook 形式で見ることができます 監査ログにはポリシーの作成が必要 監査ログの流量制限や世代管理はしっかりやること 監査ログは分析や通知をして初めて価値が出てきます クラスター管理者は監査ログを有効にしておくべき(ただし CPU/ MEM は多少 Overhead が出ることを覚悟すること)
  57. 65.

    Presented by @makocchi CloudNative Days Tokyo 2019 65 Conclusion 最後に・・・

    Kubernetes に Audit log を求めるのは 間違っているのだろうか? 間違っていません!求めていきましょう!
  58. 67.

    Presented by @makocchi CloudNative Days Tokyo 2019 67 この後続けてこの部屋で Container-native

    ロードバランシングのセッションがあります! 本イベントの最後のセッションになります。 よし良かったら見ていってください!よろしくお願いします!
  59. 68.

    CloudNative Days Tokyo 2019 Presented by @makocchi 68 Thank You

    For Your kind Attention CloudNative Days Tokyo 2019