Kebijakan audit

Halaman ini menjelaskan kebijakan logging audit untuk Google Kubernetes Engine (GKE). Untuk mendapatkan petunjuk cara mengaktifkan dan melihat berbagai jenis log audit, serta izin IAM yang diperlukan, lihat informasi logging audit GKE

Sebelum memulai

Sebelum membaca topik ini, Anda harus sudah memahami materi terkait topik berikut:

• Logging audit di GKE
• Audit di Kubernetes

Ringkasan

Di cluster GKE, server Kubernetes API menulis entri log audit ke backend yang dikelola oleh GKE. Saat menerima entri log dari server Kubernetes API, GKE akan menulisnya ke log Aktivitas Admin dan log Akses Data project Anda.

Ada dua kebijakan yang memengaruhi informasi yang Anda lihat di log audit project:

• Kebijakan audit Kubernetes menentukan aturan untuk peristiwa mana yang dicatat sebagai entri log. Kode ini juga menentukan data apa yang harus disertakan dalam entri log.

• Kebijakan audit GKE menentukan entri yang ditulis ke log Aktivitas Admin dan ditulis ke log Akses Data Anda.

Log audit yang ditulis ke log Akses Data Anda bergantung pada konfigurasi log audit Anda. Log Akses Data menggunakan harga Kemampuan Observasi Google Cloud. Log Aktivitas Admin ditawarkan tanpa biaya. GKE mendukung jenis log Akses Data berikut.

• ADMIN_READ: operasi yang membaca metadata tentang resource Kubernetes, misalnya mencantumkan Pod.
• DATA_READ: operasi yang membaca data dalam resource Kubernetes, seperti membaca log untuk Pod.
• DATA_WRITE: operasi yang menulis data ke resource Kubernetes, seperti memperbarui status Pod.

Untuk informasi selengkapnya, lihat Mengonfigurasi log audit Akses Data.

Kebijakan audit Kubernetes

Server Kubernetes API mengikuti kebijakan yang ditentukan dalam flag --audit-policy-file di perintah kube-apiserver.

Saat memulai server Kubernetes API, GKE akan menyediakan file kebijakan audit dengan menetapkan nilai flag --audit-policy-file. Di repositori Kubernetes open source, Anda dapat melihat skrip configure-helper.sh, yang menghasilkan file kebijakan audit. Anda dapat melihat sebagian besar file kebijakan audit dengan melihat langsung ke skripnya.

Peristiwa dan stage

Saat seseorang atau komponen membuat permintaan ke server Kubernetes API, permintaan tersebut akan melalui satu atau beberapa tahap:

Setiap tahap permintaan menghasilkan peristiwa, yang diproses sesuai dengan kebijakan. Kebijakan ini menentukan apakah peristiwa harus dicatat sebagai entri log dan jika ya, data apa yang harus disertakan dalam entri log.

Tingkat audit

File kebijakan audit Kubernetes berisi daftar aturan. Di file kebijakan, aturan pertama yang cocok dengan peristiwa akan menetapkan tingkat audit untuk peristiwa tersebut.

Aturan dapat menentukan salah satu tingkat audit berikut:

Berikut adalah contoh aturan. Jika peristiwa cocok dengan aturan, server Kubernetes API akan membuat entri log pada level Request.

- level: Request
  userGroups: ["system:nodes"]
  verbs: ["update","patch"]
  resources:
    - group: "" # core
      resources: ["nodes/status", "pods/status"]
  omitStages:
    - "RequestReceived"

Peristiwa cocok dengan aturan jika semua hal berikut terpenuhi:

• Peristiwa tidak cocok dengan aturan sebelumnya dalam file kebijakan.
• Identitas yang melakukan panggilan ada di grup pengguna system:nodes.
• Panggilannya adalah permintaan update atau permintaan patch.
• Permintaan berada pada resource nodes/status atau resource pods/status.
• Peristiwa bukan untuk tahap RequestReceived panggilan.

Ringkasan kebijakan audit Kubernetes untuk cluster GKE

• Secara umum, permintaan tulis seperti create, update, dan delete dicatat ke dalam log pada level RequestResponse.

• Secara umum, peristiwa get, list, dan watch dicatat pada level Metadata.

• Beberapa peristiwa diperlakukan sebagai kasus khusus. Untuk daftar definitif permintaan yang diperlakukan sebagai kasus khusus, lihat skrip kebijakan Pada saat penulisan ini, berikut adalah kasus khusus:

  • Permintaan update dan patch oleh kubelet, system:node-problem-detector, atau system:serviceaccount:kube-system:node-problem-detector pada resource nodes/status atau resource pods/status dicatat ke dalam log di Tingkat permintaan.

  • Permintaan update dan patch oleh identitas apa pun dalam grup system:nodes pada resource nodes/status atau resource pods/status dicatat ke dalam log di tingkat Permintaan.

  • Permintaan deletecollection oleh system:serviceaccount:kube-system:namespace-controller dicatat di tingkat Permintaan.

  • Permintaan pada resource secrets, resource configmaps, atau resource tokenreviews dicatat pada tingkat Metadata.

• Permintaan tertentu tidak dicatat sama sekali. Untuk daftar definitif permintaan yang tidak dicatat ke dalam log, lihat aturan level: None dalam skrip kebijakan. Pada saat penulisan ini, berikut adalah permintaan yang tidak dicatat dalam log:

  • Permintaan dari system:kube-proxy untuk mengawasi resource endpoints, resource services, atau resource services/status.

  • Dapatkan permintaan paling lambat system:unsecured pada resource configmaps di namespace kube-system.

  • Dapatkan permintaan dari kubelet pada resource nodes atau resource nodes/status.

  • Dapatkan permintaan dari identitas apa pun dalam grup system:nodes pada resource nodes atau resource nodes/status.

  • Dapatkan dan update permintaan paling lambat system:kube-controller-manager, system:kube-scheduler, atau system:serviceaccount:endpoint-controller pada resource endpoints dalam namespace kube-system.

  • Dapatkan permintaan dari system:apiserver di resource namespaces, resource namespaces/status, atau resource namespaces/finalize.

  • Mendapatkan dan mencantumkan permintaan berdasarkan system:kube-controller-manager pada resource mana pun dalam grup metrics.k8s.io.

  • Permintaan ke URL yang cocok dengan /healthz*, /version, atau /swagger*.

Kebijakan audit GKE

Karena GKE menerima entri log dari server Kubernetes API, GKE akan menerapkan kebijakannya sendiri untuk menentukan entri mana yang ditulis ke log Aktivitas Admin project Anda dan entri mana yang akan ditulis ke log Akses Data project Anda.

Secara keseluruhan, GKE menerapkan aturan berikut pada entri log yang berasal dari server Kubernetes API:

• Entri yang mewakili permintaan create, delete, dan update akan masuk ke log Aktivitas Admin Anda.

• Entri yang mewakili permintaan get, list, dan updateStatus akan masuk ke log Akses Data Anda.

Untuk mengetahui informasi tentang harga dan jenis log yang diaktifkan secara default, lihat Detail logging.

Memahami file kebijakan audit Kubernetes

Untuk cluster GKE, file kebijakan audit Kubernetes dimulai dengan aturan yang menentukan bahwa peristiwa tertentu tidak boleh dicatat sama sekali. Misalnya, aturan ini menyatakan bahwa permintaan get apa pun oleh kubelet pada resource nodes atau resource nodes/status tidak boleh dicatat ke dalam log. Ingat bahwa level None berarti peristiwa apa pun yang cocok tidak boleh dicatat ke dalam log:

- level: None
  users: ["kubelet"] # legacy kubelet identity
  verbs: ["get"]
  resources:
    - group: "" # core
    resources: ["nodes", "nodes/status"]

Setelah daftar aturan level: None, file kebijakan memiliki daftar aturan yang merupakan kasus khusus. Misalnya, berikut adalah aturan kasus khusus yang mengatakan untuk mencatat permintaan tertentu ke dalam log pada level Metadata:

- level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
    omitStages:
      - "RequestReceived"

Peristiwa cocok dengan aturan jika semua hal berikut terpenuhi:

• Peristiwa tidak cocok dengan aturan sebelumnya dalam file kebijakan.
• Permintaan pada resource jenis secrets, configmaps, atau tokenreviews.
• Peristiwa bukan untuk tahap RequestReceived panggilan.

Setelah daftar aturan kasus khusus, file kebijakan memiliki beberapa aturan umum. Untuk melihat aturan umum dalam skrip, Anda harus mengganti nilai known_apis dengan ${known_apis}. Setelah substitusi, Anda mendapatkan aturan seperti ini:

- level: Request
  verbs: ["get", "list", "watch"]
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

Aturan ini berlaku untuk peristiwa yang tidak cocok dengan aturan sebelumnya dalam file kebijakan dan tidak berada di tahap RequestReceived. Aturan tersebut menyatakan bahwa permintaan get, list, dan watch pada resource apa pun yang merupakan bagian dari salah satu grup yang tercantum harus dicatat ke dalam log pada level Request.

Aturan berikutnya dalam file kebijakan akan terlihat seperti ini:

- level: RequestResponse
  resources:
    - group: "" # core
    - group: "admissionregistration.k8s.io"
    - group: "apiextensions.k8s.io"
    - group: "apiregistration.k8s.io"
    - group: "apps"
    - group: "authentication.k8s.io"
    - group: "authorization.k8s.io"
    - group: "autoscaling"
    - group: "batch"
    - group: "certificates.k8s.io"
    - group: "extensions"
    - group: "metrics.k8s.io"
    - group: "networking.k8s.io"
    - group: "policy"
    - group: "rbac.authorization.k8s.io"
    - group: "settings.k8s.io"
    - group: "storage.k8s.io"
  omitStages:
    - "RequestReceived"

Aturan ini berlaku untuk peristiwa yang tidak cocok dengan aturan sebelumnya dalam file kebijakan dan tidak berada di tahap RequestReceived. Secara khusus, aturan ini tidak berlaku untuk permintaan baca: get, list, dan watch. Sebagai gantinya, aturan tersebut berlaku untuk permintaan tulis seperti create, update, dan delete. Aturan tersebut menyatakan bahwa permintaan tulis harus dicatat ke dalam log pada level RequestResponse.

Langkah selanjutnya

• Audit Kubernetes
• Mengakses log audit
• Ringkasan Keamanan GKE
• Cloud Audit Logs