Menggunakan logging kebijakan jaringan

Autopilot Standar

---

Halaman ini menjelaskan cara menggunakan logging kebijakan jaringan untuk Google Kubernetes Engine (GKE). Kubernetes kebijakan jaringan menentukan traffic jaringan yang boleh dikirim dan diterima oleh Pod. Logging kebijakan jaringan memungkinkan Anda merekam kapan koneksi diizinkan atau ditolak oleh kebijakan jaringan. Logging kebijakan jaringan dapat membantu Anda memecahkan masalah kebijakan jaringan.

Ringkasan

Dengan menggunakan logging kebijakan jaringan, Anda dapat:

• Memastikan bahwa kebijakan jaringan berfungsi seperti yang diharapkan.
• Memahami Pod di cluster yang berkomunikasi dengan internet.
• Memahami namespace yang berkomunikasi satu sama lain.
• Mengenali serangan Denial-of-Service.

Log kebijakan jaringan diupload ke Cloud Logging untuk keperluan penyimpanan, penelusuran, analisis, dan pemberitahuan jika Cloud Logging diaktifkan. Cloud Logging diaktifkan secara default di cluster baru. Lihat Mengonfigurasi logging dan pemantauan untuk GKE untuk mengetahui informasi lebih lanjut.

Persyaratan

• Logging kebijakan jaringan hanya tersedia untuk cluster yang menggunakan GKE Dataplane V2.
• Logging kebijakan jaringan memerlukan Google Cloud CLI 303.0.0 atau yang lebih tinggi.
• Logging kebijakan jaringan tidak didukung dengan node pool Windows Server.

Harga

• Tidak ada biaya pembuatan log untuk logging kebijakan jaringan.

• Jika Anda menyimpan log di Cloud Logging, biaya Cloud Logging standar akan berlaku.

• Log dapat dirutekan lebih lanjut ke Pub/Sub, Cloud Storage, atau menggunakan BigQuery. Biaya Pub/Sub, Cloud Storage, atau BigQuery mungkin berlaku. Untuk informasi selengkapnya, lihat Ringkasan pemilihan rute dan penyimpanan.

Mengonfigurasi logging kebijakan jaringan

Anda mengonfigurasi setelan logging kebijakan jaringan dengan mengedit objek NetworkLogging di cluster. GKE secara otomatis membuat objek NetworkLogging bernama default di cluster Dataplane V2 yang baru. Hanya boleh ada satu objek NetworkLogging per cluster dan nama objek tersebut tidak dapat diganti.

Anda dapat mengonfigurasi logging koneksi yang diizinkan dan logging koneksi yang ditolak secara terpisah. Anda juga dapat mengaktifkan logging secara selektif untuk beberapa kebijakan jaringan. Berikut adalah contoh spesifikasi NetworkLogging, dengan setelan yang ditentukan untuk mencatat semua koneksi yang diizinkan dan ditolak:

kind: NetworkLogging
apiVersion: networking.gke.io/v1alpha1
metadata:
  name: default
spec:
  cluster:
    allow:
      log: true
      delegate: false
    deny:
      log: true
      delegate: false

Gunakan kubectl untuk mengedit konfigurasi Anda:

kubectl edit networklogging default

Catatan: Jika Anda menggunakan kebijakan jaringan untuk membatasi traffic dalam Cloud Service Mesh, men-deploy kebijakan jaringan sebelum mengaktifkan Cloud Service Mesh dalam namespace. Jika tidak, koneksi jangka panjang antara Pod dalam mesh mungkin telah ditetapkan, dan mengaktifkan kebijakan jaringan baru tidak menutup koneksi yang ada.

Spesifikasi NetworkLogging

Spesifikasi objek NetworkLogging menggunakan format YAML. Format ini dijelaskan dalam tabel berikut:

Kolom	Jenis	Deskripsi
cluster.allow	struct	Setelan untuk melakukan logging koneksi yang diizinkan. Kolom Jenis Deskripsi log bool Jika ditetapkan ke true, koneksi yang diizinkan dalam cluster akan di-logging; jika terjadi sebaliknya, koneksi yang diizinkan tidak akan di-logging. Kebijakan jaringan yang memilih Pod dan memiliki aturan yang cocok dengan koneksi tercantum dalam pesan log. delegate bool Jika false, semua koneksi yang diizinkan akan di-logging. Jika beberapa kebijakan jaringan mengizinkan koneksi, semua kebijakan yang cocok akan dicantumkan dalam pesan log. Jika true, koneksi yang diizinkan hanya di-logging jika diizinkan oleh kebijakan jaringan dengan anotasi logging policy.network.gke.io/enable-logging: "true". Jika beberapa kebijakan jaringan mengizinkan koneksi, semua kebijakan yang cocok dengan anotasi enable-logging akan dicantumkan dalam pesan log. Error konfigurasi akan terjadi jika Anda menetapkan spec.cluster.allow.delegate ke true dan spec.cluster.allow.log ke false.
cluster.deny	struct	Setelan untuk logging koneksi yang ditolak. Kolom Jenis Deskripsi log bool Jika ditetapkan ke true, koneksi yang ditolak dalam cluster akan di-logging; jika terjadi sebaliknya, koneksi yang ditolak tidak akan di-logging. delegate bool Jika false, semua koneksi yang ditolak akan di-logging. Jika true, koneksi yang ditolak hanya di-logging jika Pod tempat koneksi ditolak berada dalam namespace dengan anotasi policy.network.gke.io/enable-deny-logging: "true". Error konfigurasi akan terjadi jika Anda menetapkan spec.cluster.deny.delegate ke true dan spec.cluster.deny.log ke false.

Mengakses log kebijakan jaringan

Log kebijakan jaringan diupload secara otomatis ke Cloud Logging. Anda dapat mengakses log melalui Logs Explorer atau dengan Google Cloud CLI. Anda juga dapat rutekan log ke sink.

Cloud Logging

1. Buka halaman Logs Explorer di Konsol Google Cloud.

   Buka Logs Explorer

2. Klik Query builder.

3. Gunakan kueri berikut untuk menemukan semua data log kebijakan jaringan:

   resource.type="k8s_node"
   resource.labels.location="CLUSTER_LOCATION"
   resource.labels.cluster_name="CLUSTER_NAME"
   logName="projects/PROJECT_NAME/logs/policy-action"
   

   Ganti kode berikut:

   • CLUSTER_LOCATION: Lokasi Compute Engine dari cluster tersebut.
   • CLUSTER_NAME: Nama cluster Anda.
   • PROJECT_NAME: Nama project Google Cloud Anda.

Lihat Menggunakan Logs Explorer untuk mempelajari cara menggunakan Logs Explorer.

Anda juga dapat membuat kueri menggunakan Query builder. Guna membuat kueri untuk log kebijakan jaringan, pilih policy-action di menu drop-down Log name. Jika tidak ada log yang tersedia, policy-action tidak akan muncul di menu drop-down.

gcloud

Menemukan semua data log kebijakan jaringan:

gcloud logging read --project "PROJECT_NAME" 'resource.type="k8s_node"
    resource.labels.location="CLUSTER_LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    logName="projects/PROJECT_NAME/logs/policy-action"'

Ganti kode berikut:

• PROJECT_NAME: Nama project Google Cloud Anda.
• CLUSTER_LOCATION: Lokasi Compute Engine dari cluster tersebut.
• CLUSTER_NAME: Nama cluster Anda.

Anda dapat menambahkan kondisi lainnya untuk memfilter hasil. Contoh:

• Menampilkan log dalam jangka waktu tertentu:

  timestamp>="2020-06-22T06:30:51.128Z"
  timestamp<="2020-06-23T06:30:51.128Z"
  

• Menampilkan log untuk koneksi yang ditolak:

  jsonPayload.disposition="deny"
  

• Menampilkan log ke deployment bernama "redis":

  jsonPayload.dest.pod_name=~"redis"
  jsonPayload.dest.pod_namespace="default"
  

• Menampilkan log untuk koneksi eksternal cluster:

  jsonPayload.dest.instance != ""
  

• Menampilkan log yang cocok dengan kebijakan jaringan tertentu, dalam hal ini "allow-frontend-to-db":

  jsonPayload.policies.name="allow-frontend-to-db"
  jsonPayload.policies.namespace="default"
  

Jika menggunakan cluster Standard, Anda juga dapat menemukan log kebijakan jaringan yang dihasilkan pada setiap node cluster secara lokal di /var/log/network/policy_action.log*. File log bernomor baru akan dibuat saat file log saat ini mencapai 10 MB. Hingga lima file log sebelumnya akan disimpan.

Format log kebijakan jaringan

Data log kebijakan jaringan dalam format JSON. Format ini dijelaskan dalam tabel berikut:

Kolom	Jenis	Deskripsi
connection	struct	Informasi koneksi: Kolom Jenis Deskripsi src_ip string Alamat IP sumber koneksi. src_port int Port sumber koneksi. dest_ip string Alamat IP tujuan koneksi. dest_port int Port tujuan koneksi. protocol string Protokol koneksi, yang dapat berupa salah satu dari tcp, udp, atau icmp. direction string Arah koneksi, yang dapat berupa ingress, atau egress.
src	struct	Informasi endpoint sumber: Kolom Jenis Deskripsi pod_name string Nama Pod, jika sumbernya adalah Pod. pod_namespace (deprecated) string Namespace Pod, jika sumbernya adalah Pod. pod_namespace tidak digunakan lagi. Sebagai gantinya, gunakan namespace. namespace string Namespace Pod, jika sumbernya adalah Pod. workload_name string Nama workload, jika workload sumber tersedia. workload_kind string Jenis workload, jika workload sumber tersedia. instance string Alamat IP sumber, jika sumber bukan Pod.
dest	struct	Informasi endpoint tujuan: Kolom Jenis Deskripsi pod_name string Nama Pod, jika tujuannya adalah Pod. pod_namespace (deprecated) string Namespace Pod, jika tujuannya adalah Pod. pod_namespace tidak digunakan lagi. Sebagai gantinya, gunakan namespace. namespace string Namespace Pod, jika tujuannya adalah Pod. workload_name string Nama workload, jika workload tujuan tersedia. workload_kind string Jenis workload, jika workload tujuan tersedia. instance string Alamat IP sumber, jika tujuan bukan Pod.
disposition	string	Disposisi koneksi, yang dapat berupa allow atau deny.
policies	list of structs	Kebijakan yang cocok untuk koneksi yang diizinkan dari tampilan Pod yang diterapkan. Untuk koneksi masuk, Pod yang diterapkan adalah Pod tujuan. Untuk koneksi traffic keluar, Pod yang diterapkan adalah Pod sumber. Beberapa kebijakan akan di-logging jika koneksi cocok oleh semuanya. Kolom ini hanya disertakan dalam log koneksi yang diizinkan. Kolom Jenis Deskripsi name string Nama kebijakan jaringan yang cocok. namespace string Namespace kebijakan jaringan yang cocok.
count	int	Digunakan untuk agregasi log kueri yang ditolak. Nilainya selalu 1 untuk koneksi yang diizinkan.
node_name	string	Node yang menjalankan Pod yang menghasilkan pesan log ini.
timestamp	string	Saat upaya koneksi terjadi.

Catatan: namespace, workload_name, dan workload_kind tersedia dalam versi berikut:

• 1.20.10-gke.2200 hingga 1.21
• 1.21.4-gke.2300 hingga 1.22
• 1.22.1-gke.1700 dan yang lebih baru

Definisi koneksi

Untuk protokol connection-oriented seperti TCP, log dibuat untuk setiap koneksi yang diizinkan atau ditolak. Untuk protokol seperti UDP dan ICMP yang tidak connection-oriented, paket dikelompokkan ke dalam koneksi berbasis jangka waktu.

Log kebijakan untuk koneksi yang ditolak

Data log untuk koneksi yang ditolak tidak menyertakan kolom policies karena API kebijakan jaringan Kubernetes tidak memiliki kebijakan penolakan yang eksplisit. Koneksi ditolak jika Pod tercakup oleh satu atau beberapa kebijakan jaringan, tetapi tidak ada kebijakan yang mengizinkan koneksi tersebut. Artinya, tidak ada kebijakan yang secara individual bertanggung jawab atas koneksi yang diblokir.

Agregasi log untuk koneksi yang ditolak

Hal ini umum bagi klien untuk mencoba kembali koneksi yang ditolak. Untuk mencegah logging yang berlebihan, koneksi yang ditolak berulang dalam jendela lima detik digabungkan ke dalam satu pesan log menggunakan kolom count.

Koneksi berikutnya yang ditolak akan digabungkan dengan pesan log sebelumnya jika src_ip, dest_ip, dest_port, protocol, dan direction koneksi cocok dengan koneksi pertama yang ditolak. Perhatikan bahwa src_port koneksi berikutnya tidak harus cocok karena koneksi yang dicoba lagi mungkin berasal dari port yang berbeda. Pesan log gabungan menyertakan src_prt koneksi pertama yang ditolak di awal jendela agregasi.

Contoh data log

Contoh kebijakan jaringan berikut bernama allow-green yang diterapkan ke test-service mengizinkan koneksi ke test-service dari Pod bernama client-green. Secara implisit, kebijakan ini menolak semua traffic ingress lainnya ke test-service termasuk dari Pod client-red.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-green
    namespace: default
    annotations:
      policy.network.gke.io/enable-logging: "true"
  spec:
    podSelector:
      matchLabels:
        app: test-service
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: client-green
    policyTypes:
    - Ingress

Diagram ini menunjukkan efek kebijakan allow-green pada dua koneksi ke test-service. Kebijakan allow-green mengizinkan koneksi dari client-green. Karena tidak ada kebijakan yang mengizinkan koneksi dari client-red, koneksi akan ditolak.

Log untuk koneksi yang diizinkan dari client-green akan terlihat seperti ini:

{
   "connection":{
      "src_ip":"10.84.0.252",
      "dest_ip":"10.84.0.165",
      "src_port":52648,
      "dest_port":8080,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"allow",
   "policies":[
      {
         "name":"allow-green",
         "namespace":"default"
      }
   ],
   "src":{
      "pod_name":"client-green-7b78d7c957-68mv4",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"client-green-7b78d7c957",
      "workload_kind":"ReplicaSet"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"test-service-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":1,
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2020-06-16T03:10:37.993712906Z"
}

Log untuk koneksi yang ditolak dari client-red akan terlihat seperti ini:

{
   "connection":{
      "src_ip":"10.84.0.180",
      "dest_ip":"10.84.0.165",
      "src_port":39610,
      "dest_port":8080,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"deny",
   "src":{
      "pod_name":"client-red-5689846f5b-b5ccx",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"client-red-5689846f5b",
      "workload_kind":"ReplicaSet"
   },
   "dest":{
      "pod_name":"test-service-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"test-service-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":3,
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2020-06-15T22:38:32.189649531Z"
}

Perhatikan bahwa log koneksi yang ditolak tidak menyertakan kolom policies. Ini dijelaskan di bagian sebelumnya, Log kebijakan untuk koneksi yang ditolak.

Log koneksi yang ditolak mencakup kolom count untuk menggabungkan koneksi yang ditolak.

Memecahkan masalah pada log kebijakan jaringan

1. Periksa peristiwa error dalam objek NetworkLogging:

   kubectl describe networklogging default
   

   Jika konfigurasi {i>logging<i} tidak valid, konfigurasi tidak akan mengambil dan error akan dilaporkan di bagian peristiwa:

   Name:         default
   Namespace:
   Labels:       addonmanager.kubernetes.io/mode=EnsureExists
   Annotations:  API Version:  networking.gke.io/v1alpha1
   Kind:         NetworkLogging
   Metadata:
     Creation Timestamp:  2020-06-20T05:54:08Z
     Generation:          8
     Resource Version:    187864
     Self Link:           /apis/networking.gke.io/v1alpha1/networkloggings/default
     UID:                 0f1ddd6e-4193-4295-9172-baa6a52aa6e6
   Spec:
     Cluster:
       Allow:
         Delegate:  true
         Log:       false
       Deny:
         Delegate:  false
         Log:       false
   Events:
     Type     Reason                 Age                From                                                               Message
     ----     ------                 ----               ----                                                               -------
     Warning  InvalidNetworkLogging  16s (x3 over 11h)  network-logging-controller, gke-anthos-default-pool-cee49209-0t09  cluster allow log action is invalid: delegate cannot be true when log is false
     Warning  InvalidNetworkLogging  16s (x3 over 11h)  network-logging-controller, gke-anthos-default-pool-cee49209-80fx  cluster allow log action is invalid: delegate cannot be true when log is false
   

2. Untuk membatasi penggunaan CPU yang dihabiskan untuk logging, sebuah node dapat membuat log hingga 500 koneksi per detik sebelum mulai menghapus log. Kebijakan jaringan pada node masih diberlakukan. Anda dapat melihat apakah ada log kebijakan yang dihapus dengan memeriksa apakah penghitung error bertambah:

   kubectl exec ANETD_POD_NAME -n kube-system -- curl -s http://localhost:9990/metrics |grep policy_logging
   

   Ganti ANETD_POD_NAME dengan nama anetd Pod. Periksa setiap node. anetd adalah pengontrol jaringan untuk Dataplane V2.

Log tanpa nama akan muncul untuk Pod dengan kebijakan penolakan default

Pemeriksaan keaktifan, kesiapan, dan startup mengharuskan Pod menerima koneksi Ingress yang dibuat oleh probe dari kubelet. Untuk memastikan pemeriksaan ini berfungsi dengan benar, GKE otomatis mengizinkan pemeriksaan traffic ke Pod yang dipilih sebagaimana dikonfigurasi untuk Pod, terlepas dari kebijakan jaringan yang diterapkan pada Pod. Anda tidak dapat mengubah perilaku ini.

Log untuk memeriksa koneksi mirip dengan berikut ini:

{
   "connection":{
      "src_ip":"10.88.1.1",
      "dest_ip":"10.88.1.4",
      "src_port":35848,
      "dest_port":15021,
      "protocol":"tcp",
      "direction":"ingress"
   },
   "disposition":"allow",
   "src":{
      "instance":"10.88.1.1"
   },
   "dest":{
      "pod_name":"testpod-745c798fc9-sfd9h",
      "pod_namespace":"default",
      "namespace":"default",
      "workload_name":"testpod-745c798fc9",
      "workload_kind":"ReplicaSet"
   },
   "count":1,
   "policies": [
     {
       "name":""
     }
    ],
   "node_name":"gke-demo-default-pool-5dad52ed-k0h1",
   "timestamp":"2021-04-01T12:42:32.1898720941Z"
}

Log tersebut memiliki karakteristik berikut:

• Nilai policies.name kosong karena tidak ada kebijakan jaringan terkait untuk mengizinkan koneksi.
• Nilai connection.src_ip tidak sesuai dengan Pod atau node mana pun.

Langkah berikutnya

• Pelajari cara melihat dan menganalisis log dengan Cloud Logging.
• Menerapkan pendekatan umum untuk membatasi traffic menggunakan kebijakan jaringan.

• Pelajari cara melihat konektivitas workload dengan GKE Dataplane V2.