Memahami keamanan jaringan di GKE

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

Di Google Kubernetes Engine (GKE), menerapkan prinsip hak istimewa terendah pada traffic jaringan berarti membatasi komunikasi hanya pada apa yang diperlukan agar aplikasi Anda berfungsi. Secara default, jaringan dalam cluster GKE bersifat terbuka, yang berarti setiap Pod dapat berkomunikasi dengan 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 Google Cloud, lihat Peran dan tugas pengguna GKE umum.

Sebelum membaca dokumen ini, pastikan Anda memahami hal-hal berikut:

  • Konsep jaringan GKE: untuk ringkasan, 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.

Tujuan keamanan jaringan GKE

Kebijakan keamanan jaringan GKE memberikan kontrol traffic yang sangat detail dan kompatibel dengan Kubernetes dalam cluster Anda. Kebijakan ini merupakan elemen penting dalam strategi keamanan Anda secara keseluruhan. Untuk menerapkan keamanan jaringan yang tangguh, pertimbangkan prinsip-prinsip dasar berikut:

  • Hak istimewa terendah: berikan hanya hak istimewa minimum kepada sistem dan layanan yang diperlukan untuk menjalankan fungsinya. Prinsip ini mengurangi potensi dampak penyusupan. Kebijakan jaringan Kubernetes membantu Anda beralih dari jaringan terbuka default ke jaringan yang hanya mengizinkan koneksi yang diperlukan.
  • Defense in depth: menerapkan beberapa kontrol keamanan yang independen. Kegagalan dalam satu kontrol tidak menyebabkan penyusupan sistem secara total. Misalnya, Anda menggunakan kebijakan jaringan untuk mengisolasi database, meskipun database itu sendiri memerlukan autentikasi.
  • Data yang dapat ditindaklanjuti: mendasarkan keputusan keamanan pada data. Pemodelan ancaman dan penilaian risiko akan memengaruhi 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 mikroservice berkomunikasi satu sama lain, gunakan kebijakan yang beroperasi pada label dan namespace Pod.

    • Sebagai developer aplikasi, gunakan NetworkPolicy Kubernetes standar untuk menentukan aturan ingress dan egress untuk aplikasi Anda dalam namespace-nya.
    • Sebagai administrator cluster, gunakan CiliumClusterwideNetworkPolicy untuk menerapkan batas keamanan yang berlaku untuk seluruh cluster. Aturan penolakan di NetworkPolicy lebih diprioritaskan daripada aturan izin 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 saat alamat IP layanan eksternal tidak statis, karena kebijakan ini secara otomatis menyelesaikan 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 mesh layanan. Gunakan Istio atau Anthos Cloud Service Mesh untuk menerapkan TLS bersama (mTLS), yang secara otomatis menangani enkripsi.

Ringkasan pilihan kebijakan

Tabel berikut merangkum kebijakan yang harus digunakan berdasarkan tujuan keamanan Anda.

Sasaran Kebijakan yang direkomendasikan
Mengontrol traffic antar-Pod menggunakan label dan namespace. Kubernetes NetworkPolicy
Mengontrol traffic keluar ke layanan eksternal menurut nama domain. FQDNNetworkPolicy
Enkripsi dan autentikasi semua traffic layanan-ke-layanan. Istio atau Anthos Cloud Service Mesh (untuk mTLS)
Terapkan 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, pastikan kebijakan tersebut berfungsi seperti yang diharapkan dan diagnostik masalah konektivitas. Anda dapat menggunakan Logging Kebijakan Jaringan sebagai alat utama untuk melakukannya.

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 sesuai yang diharapkan dan traffic yang tidak sah diblokir.

Langkah berikutnya