Memahami keamanan jaringan di GKE

Dokumen ini menjelaskan konsep inti keamanan jaringan GKE, seperti prinsip hak istimewa terendah, dan membantu Anda memilih alat yang tepat untuk mengamankan cluster. Tujuan utama penerapan keamanan jaringan GKE adalah isolasi workload dan multi-tenancy yang aman. Untuk mencapai tujuan ini, Anda harus menerapkan prinsip hak istimewa terendah, defense in depth, dan menggunakan data yang dapat ditindaklanjuti untuk menginformasikan keputusan keamanan Anda.

Di Google Kubernetes Engine (GKE), menerapkan prinsip hak istimewa terendah ke traffic jaringan berarti membatasi komunikasi hanya pada hal yang diperlukan agar aplikasi Anda berfungsi. Secara default, jaringan dalam cluster GKE terbuka, yang berarti setiap Pod dapat berkomunikasi dengan setiap Pod lainnya.

Dokumen ini membantu Operator, spesialis Jaringan, dan spesialis Keamanan memahami dan menerapkan keamanan jaringan dalam cluster GKE. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas di Cloud de Confiance by S3NS, lihat Peran dan tugas pengguna GKE umum.

Sebelum membaca dokumen ini, pastikan Anda memahami hal berikut:

  • Konsep jaringan GKE: untuk ringkasannya, lihat Tentang jaringan GKE.
  • Pod, Layanan, dan namespace Kubernetes: resource Kubernetes mendasar ini sangat penting untuk menentukan kebijakan keamanan jaringan. Lihat dokumentasi Kubernetes.
  • Prinsip hak istimewa terendah: prinsip keamanan ini adalah konsep inti yang diterapkan di seluruh dokumen ini.

Sasaran keamanan jaringan GKE

Kebijakan keamanan jaringan GKE menyediakan kontrol traffic yang mendetail dan Kubernetes-aware dalam cluster Anda. Kebijakan ini merupakan elemen penting dari strategi keamanan Anda secara keseluruhan. Untuk menerapkan keamanan jaringan yang kuat, pertimbangkan prinsip-prinsip mendasar berikut:

  • Hak istimewa terendah: berikan sistem dan layanan hanya hak istimewa minimum yang diperlukan untuk menjalankan fungsinya. Prinsip ini mengurangi potensi dampak dari penyusupan. Kebijakan jaringan Kubernetes membantu Anda beralih dari jaringan terbuka default ke jaringan yang hanya mengizinkan koneksi yang diperlukan.
  • Defense in depth: lapisi beberapa kontrol keamanan independen. Kegagalan dalam satu kontrol tidak menyebabkan penyusupan sistem total. Misalnya, Anda menggunakan kebijakan jaringan untuk mengisolasi database, meskipun database itu sendiri memerlukan autentikasi.
  • Data yang dapat ditindaklanjuti: buat keputusan keamanan berdasarkan data. Pemodelan ancaman dan penilaian risiko menginformasikan postur keamanan Anda. Fitur seperti logging kebijakan jaringan menyediakan data untuk memverifikasi kebijakan dan mendeteksi potensi pelanggaran.

Memilih kebijakan keamanan jaringan

Untuk memilih kebijakan yang tepat, identifikasi jenis dan cakupan traffic yang perlu Anda kontrol.

Jenis traffic

Untuk memilih kebijakan yang tepat, pertimbangkan sumber dan tujuan traffic yang ingin Anda kelola:

  • Komunikasi antara Pod dalam cluster: untuk mengontrol cara microservice berkomunikasi satu sama lain, gunakan kebijakan yang beroperasi pada label dan namespace Pod.

    • Sebagai developer aplikasi, gunakan standar Kubernetes NetworkPolicy untuk menentukan aturan masuk dan keluar untuk aplikasi Anda dalam namespace-nya.
    • Sebagai administrator cluster, gunakan CiliumClusterwideNetworkPolicy untuk menerapkan batasan keamanan yang berlaku untuk seluruh cluster. Aturan tolak di NetworkPolicy lebih diutamakan daripada aturan izinkan CiliumClusterwideNetworkPolicy.

  • Traffic keluar dari Pod ke layanan eksternal: untuk mengontrol traffic keluar dari Pod ke layanan eksternal berdasarkan nama domain, gunakan FQDNNetworkPolicy. Kebijakan ini berguna jika alamat IP layanan eksternal tidak statis, karena kebijakan ini secara otomatis me-resolve dan memperbarui alamat IP yang diizinkan berdasarkan DNS.

  • Enkripsi untuk semua traffic layanan ke layanan: untuk membantu memastikan semua komunikasi antar-layanan dienkripsi dan diautentikasi, gunakan service mesh. Gunakan Istio atau Anthos Cloud Service Mesh untuk menerapkan TLS timbal balik (mTLS), yang otomatis menangani enkripsi.

Ringkasan pilihan kebijakan

Tabel berikut merangkum kebijakan yang akan digunakan berdasarkan sasaran keamanan Anda.

Sasaran Kebijakan yang direkomendasikan
Mengontrol traffic antara Pod menggunakan label dan namespace. Kubernetes NetworkPolicy
Mengontrol traffic keluar ke layanan eksternal berdasarkan nama domain. FQDNNetworkPolicy
Mengenkripsi dan mengautentikasi semua traffic layanan ke layanan. Istio atau Anthos Cloud Service Mesh (untuk mTLS)
Menerapkan aturan wajib di seluruh cluster sebagai administrator. CiliumClusterwideNetworkPolicy
Mengaudit dan mencatat koneksi yang diizinkan atau ditolak oleh kebijakan. logging kebijakan jaringan (diaktifkan untuk kebijakan apa pun)

Mengaudit dan memecahkan masalah kebijakan jaringan

Setelah menerapkan kebijakan jaringan, verifikasi bahwa kebijakan tersebut berfungsi seperti yang diharapkan dan diagnosis masalah konektivitas apa pun. Anda dapat menggunakan Logging Kebijakan Jaringan sebagai alat utama untuk hal ini.

Saat Anda mengaktifkan logging kebijakan jaringan, GKE akan membuat catatan log di Cloud Logging untuk setiap koneksi yang diizinkan atau ditolak oleh kebijakan jaringan. Log ini penting untuk melakukan audit keamanan dan memecahkan masalah perilaku yang tidak terduga. Dengan meninjau log ini, Anda dapat melihat efek konkret dari aturan Anda, yang mengonfirmasi bahwa traffic yang sah mengalir seperti yang diharapkan dan traffic yang tidak sah diblokir.

Langkah berikutnya