Ringkasan Keamanan

Google Kubernetes Engine (GKE) menyediakan banyak cara untuk membantu mengamankan workload Anda. Perlindungan workload di GKE melibatkan banyak lapisan stack, termasuk konten image container, runtime container, jaringan cluster, dan akses ke server API cluster.

Sebaiknya ambil pendekatan berlapis untuk melindungi cluster dan workload. Anda dapat menerapkan prinsip hak istimewa terendah ke tingkat akses yang diberikan kepada pengguna dan aplikasi. Di setiap lapisan, mungkin ada kompromi berbeda yang harus dilakukan, sehingga memungkinkan tingkat fleksibilitas dan keamanan yang tepat bagi organisasi Anda untuk men-deploy dan mengelola workload dengan aman. Misalnya, beberapa setelan keamanan mungkin terlalu membatasi jenis aplikasi atau kasus penggunaan tertentu agar dapat berfungsi tanpa pemfaktoran ulang yang signifikan.

Dokumen ini memberikan ringkasan setiap lapisan infrastruktur, dan menunjukkan cara mengonfigurasi fitur keamanannya agar sesuai dengan kebutuhan Anda.

Autentikasi dan otorisasi

Kubernetes mendukung dua jenis autentikasi:

  1. Akun pengguna adalah akun yang dikenal menggunakan Kubernetes, tetapi tidak dikelola oleh Kubernetes. Misalnya, Anda tidak dapat membuat atau menghapusnya menggunakan kubectl.
  2. Akun layanan adalah akun yang dibuat dan dikelola oleh Kubernetes, tetapi hanya dapat digunakan oleh entity yang dibuat Kubernetes, seperti pod.

Dalam cluster GKE, akun pengguna Kubernetes dikelola oleh Google Cloud, dan dapat merupakan salah satu dari dua jenis berikut:

  1. Akun Google
  2. Akun layanan Google Cloud

Setelah diautentikasi, Anda harus mengizinkan identitas ini untuk membuat, membaca, mengupdate, atau menghapus resource Kubernetes.

Meskipun namanya mirip, akun layanan Kubernetes dan akun layanan Google Cloud merupakan entity yang berbeda. Akun layanan Kubernetes adalah bagian dari cluster tempat akun tersebut ditentukan dan biasanya digunakan dalam cluster tersebut. Sebaliknya, akun layanan Google Cloud adalah bagian dari project Google Cloud, dan dapat dengan mudah diberi izin baik di dalam cluster dan ke cluster project Google Cloud itu sendiri, serta ke resource Google Cloud apa pun yang menggunakan Identity and Access Management (IAM). Hal ini membuat akun layanan Google Cloud lebih andal daripada akun layanan Kubernetes; untuk mengikuti prinsip keamanan dengan hak istimewa terendah, sebaiknya gunakan akun layanan Google Cloud hanya jika kemampuannya diperlukan.

Untuk mengonfigurasi akses yang lebih terperinci ke resource Kubernetes di level cluster atau dalam namespace Kubernetes, gunakan Role-Based Access Control (RBAC). Dengan RBAC, Anda dapat membuat kebijakan mendetail yang menentukan operasi dan resource yang boleh diakses oleh pengguna dan akun layanan. Dengan RBAC, Anda dapat mengontrol akses untuk Akun Google, akun layanan Google Cloud, dan akun layanan Kubernetes. Untuk lebih menyederhanakan dan menyederhanakan strategi autentikasi dan otorisasi untuk GKE, Anda harus memastikan bahwa Kontrol Akses Berbasis Atribut yang lama dinonaktifkan sehingga Kubernetes RBAC dan IAM adalah sumbernya yang benar.

Untuk informasi selengkapnya:

Keamanan bidang kontrol

Di GKE, komponen bidang kontrol Kubernetes dikelola dan dikelola oleh Google. Komponen bidang kontrol menghosting software yang menjalankan bidang kontrol Kubernetes, termasuk server API, penjadwal, pengelola pengontrol, dan database etcd tempat konfigurasi Kubernetes Anda disimpan.

Anda dapat mengakses bidang kontrol menggunakan endpoint berbasis DNS (direkomendasikan), endpoint berbasis IP, atau keduanya. Jika menggunakan endpoint berbasis IP, Anda dapat melindungi server Kubernetes API menggunakan jaringan yang diizinkan dan tidak mengaktifkan endpoint eksternal bidang kontrol. Tindakan ini memungkinkan Anda menetapkan alamat IP internal ke bidang kontrol dan menonaktifkan akses di alamat IP eksternal. Jika menggunakan endpoint berbasis DNS, Anda dapat menggunakan IAM dan Kontrol Layanan VPC untuk mengamankan akses bidang kontrol dengan kebijakan identitas dan kebijakan berbasis jaringan.

Anda dapat menangani autentikasi cluster di Google Kubernetes Engine dengan menggunakan IAM sebagai penyedia identitas. Untuk mengetahui informasi tentang autentikasi, baca bagian Mengautentikasi ke server Kubernetes API.

Cara lain untuk membantu mengamankan bidang kontrol adalah dengan memastikan Anda melakukan rotasi kredensial secara rutin. Saat rotasi kredensial dimulai, sertifikat SSL dan otoritas sertifikat cluster akan dirotasi. Proses ini diotomatiskan oleh GKE dan juga memastikan bahwa alamat IP bidang kontrol Anda berputar.

Untuk informasi selengkapnya:

Keamanan node

GKE men-deploy workload Anda di instance Compute Engine yang berjalan di project Google Cloud Anda. Instance ini dilampirkan ke cluster GKE Anda sebagai node. Bagian berikut menunjukkan cara memanfaatkan fitur keamanan tingkat node yang tersedia untuk Anda di Google Cloud.

Container-Optimized OS

Secara default, node GKE menggunakan Container-Optimized OS Google sebagai sistem operasi yang akan digunakan untuk menjalankan Kubernetes beserta komponennya. Container-Optimized OS menerapkan beberapa fitur lanjutan untuk meningkatkan keamanan cluster GKE, termasuk:

  • Firewall yang terkunci
  • Jika memungkinkan, sistem file hanya-baca
  • Akun pengguna terbatas dan login root dinonaktifkan

Node GKE Autopilot selalu menggunakan Container-Optimized OS sebagai sistem operasi.

Upgrade node

Praktik terbaik adalah mem-patch OS secara teratur. Dari waktu ke waktu, masalah keamanan dalam runtime container, Kubernetes itu sendiri, atau sistem operasi node mungkin mengharuskan Anda untuk mengupgrade node dengan lebih cepat. Saat Anda mengupgrade node, software node akan diupgrade ke versi terbarunya.

Cluster GKE mendukung upgrade otomatis. Dalam cluster Autopilot, upgrade otomatis selalu diaktifkan. Anda juga dapat mengupgrade node secara manual dalam cluster Standar.

Melindungi node dari workload yang tidak tepercaya

Untuk cluster yang menjalankan beban kerja yang tidak diketahui atau tidak tepercaya, praktik yang baik adalah melindungi sistem operasi pada node dari workload tidak tepercaya yang berjalan di Pod.

Misalnya, cluster multi-tenant seperti penyedia software-as-a-service (SaaS) sering menjalankan kode tidak dikenal yang dikirimkan oleh penggunanya. Riset keamanan adalah aplikasi lain dengan beban kerja mungkin memerlukan isolasi yang lebih kuat daripada yang disediakan node secara default.

Anda dapat mengaktifkan GKE Sandbox di cluster untuk mengisolasi workload tidak tepercaya di sandbox pada node. GKE Sandbox dibuat menggunakan gVisor, sebuah project open source.

Mengamankan metadata instance

GKE menggunakan metadata instance dari instance Compute Engine yang mendasarinya untuk memberikan kredensial dan konfigurasi yang digunakan untuk melakukan bootstrap pada node dan terhubung ke bidang kontrol. Metadata ini berisi informasi sensitif yang tidak perlu diakses oleh Pod pada node, seperti kunci akun layanan node.

Anda dapat mengunci jalur metadata instance yang sensitif menggunakan Workload Identity Federation for GKE. Workload Identity Federation for GKE mengaktifkan server metadata GKE di cluster Anda, yang memfilter permintaan ke kolom sensitif seperti kube-env.

Workload Identity Federation for GKE selalu diaktifkan di cluster Autopilot. Dalam cluster Standard, Pod memiliki akses ke metadata instance, kecuali jika Anda mengaktifkan Workload Identity Federation untuk GKE secara manual.

Keamanan jaringan

Sebagian besar beban kerja yang berjalan di GKE perlu berkomunikasi dengan layanan lain yang dapat berjalan baik di dalam atau di luar cluster. Anda dapat menggunakan beberapa metode berbeda untuk mengontrol traffic yang diizinkan mengalir melalui cluster Anda dan Pod-nya.

Membatasi komunikasi Pod ke Pod

Secara default, semua Pod dalam cluster dapat dijangkau melalui jaringan melalui alamat IP Pod mereka. Demikian pula, secara default, traffic keluar memungkinkan koneksi keluar ke alamat mana pun yang dapat diakses di VPC tempat cluster di-deploy.

Administrator cluster dan pengguna dapat mengunci koneksi masuk dan keluar yang dibuat ke dan dari Pod dalam namespace menggunakan kebijakan jaringan. Secara default, jika tidak ada kebijakan jaringan yang ditentukan, semua traffic masuk dan keluar diizinkan untuk mengalir ke dalam dan keluar dari semua Pod. Kebijakan jaringan memungkinkan Anda menggunakan tag untuk menentukan traffic yang mengalir melalui Pod Anda.

Setelah kebijakan jaringan diterapkan dalam namespace, semua traffic akan diturunkan ke dan dari Pod yang tidak cocok dengan label yang dikonfigurasi. Sebagai bagian dari pembuatan cluster dan/atau namespace, Anda dapat menerapkan traffic tolak default ke traffic masuk dan keluar dari setiap Pod untuk memastikan bahwa semua workload baru yang ditambahkan ke cluster harus secara eksplisit memberi otorisasi lalu lintas data yang diperlukan.

Untuk informasi selengkapnya:

Memfilter traffic dengan load balancing

Untuk melakukan load balancing pada Pod Kubernetes dengan load balancer jaringan, Anda perlu membuat Service jenis LoadBalancer yang sesuai dengan label Pod Anda. Setelah Service dibuat, Anda akan memiliki IP eksternal yang memetakan ke port di Pod Kubernetes Anda. Pemfilteran traffic yang diizinkan dapat dilakukan di level node oleh kube-proxy, yang memfilter berdasarkan alamat IP.

Untuk mengonfigurasi pemfilteran ini, Anda dapat menggunakan konfigurasi loadBalancerSourceRanges objek Service. Dengan parameter konfigurasi ini, Anda dapat memberikan daftar rentang CIDR yang ingin Anda izinkan untuk mengakses Service. Jika Anda tidak mengonfigurasi loadBalancerSourceRanges, semua alamat akan diizinkan untuk mengakses Service melalui IP eksternalnya.

Jika akses eksternal ke Service tidak diperlukan, pertimbangkan untuk menggunakan load balancer internal. Load balancer internal juga mematuhi loadBalancerSourceRanges saat diperlukan untuk memfilter traffic dari dalam VPC.

Untuk mengetahui informasi selengkapnya, ikuti tutorial load balancing internal.

Mengamankan workload Anda

Dengan Kubernetes, pengguna dapat menyediakan, menskalakan, dan memperbarui beban kerja berbasis container dengan cepat. Bagian ini menjelaskan taktik yang dapat diterapkan oleh administrator dan pengguna untuk membatasi efek yang dapat dimiliki container yang berjalan pada container lain di cluster yang sama, node tempat container dapat dijalankan, dan layanan Google Cloud yang diaktifkan di proyek pengguna.

Membatasi hak istimewa proses container Pod

Membatasi hak istimewa pada proses dalam container sangat penting untuk keamanan cluster Anda secara keseluruhan. Cluster GKE Autopilot selalu membatasi hak istimewa tertentu, seperti yang dijelaskan dalam Kemampuan keamanan Autopilot.

GKE juga memungkinkan Anda menyetel opsi terkait keamanan melalui Konteks Keamanan di Pod dan container. Pengaturan ini memungkinkan Anda mengubah pengaturan keamanan proses Anda seperti:

  • Pengguna dan grup untuk dijalankan sebagai
  • Kemampuan Linux yang tersedia
  • Kemampuan untuk mengeskalasi hak istimewa

Untuk menerapkan pembatasan ini di tingkat cluster, bukan di tingkat Pod atau container, gunakan pengontrol PodSecurityAdmission. Administrator cluster dapat menggunakan PodSecurityAdmission untuk memastikan bahwa semua Pod di cluster atau namespace mematuhi kebijakan yang telah ditetapkan sebelumnya dalam Standar Keamanan Pod. Anda juga dapat menetapkan kebijakan keamanan Pod kustom di tingkat cluster menggunakan Gatekeeper.

Sistem operasi node GKE, baik Container-Optimized OS dan Ubuntu, menerapkan kebijakan keamanan Docker AppArmor default ke semua container yang dimulai oleh Kubernetes. Anda dapat melihat template profil di GitHub. Di antara berbagai hal lainnya, profil menolak kemampuan berikut untuk container:

  • Menulis file langsung di /proc/
  • Menulis ke file yang tidak ada dalam direktori ID proses (/proc/<number>)
  • Menulis ke file di /proc/sys selain /proc/sys/kernel/shm*
  • Memasang sistem file

Untuk informasi selengkapnya:

Memberi Pod akses ke resource Google Cloud

Container dan Pod Anda mungkin memerlukan akses ke resource lain di Google Cloud. Ada tiga cara untuk melakukan ini.

Cara paling aman untuk mengizinkan Pod mengakses resource Google Cloud adalah dengan Workload Identity Federation untuk GKE. Workload Identity Federation for GKE memungkinkan akun layanan Kubernetes dijalankan sebagai akun layanan IAM. Pod yang dijalankan sebagai akun layanan Kubernetes memiliki izin akun layanan IAM.

Workload Identity Federation for GKE dapat digunakan dengan GKE Sandbox.

Akun layanan node

Dalam cluster Standard, Pod Anda juga dapat melakukan autentikasi ke Google Cloud menggunakan kredensial akun layanan yang digunakan oleh virtual machine (VM) Compute Engine node.

Pendekatan ini tidak kompatibel dengan GKE Sandbox karena GKE Sandbox memblokir akses ke server metadata Compute Engine.

Anda dapat memberikan kredensial untuk resource Google Cloud kepada aplikasi menggunakan kunci akun layanan. Pendekatan ini sangat tidak disarankan karena sulitnya mengelola kunci akun dengan aman.

Jika Anda memilih metode ini, gunakan akun layanan IAM kustom untuk setiap aplikasi sehingga aplikasi memiliki izin minimal yang diperlukan. Berikan peran IAM minimum yang diperlukan agar aplikasi yang dipasangkan dapat beroperasi dengan sukses ke setiap akun layanan. Mempertahankan akun layanan khusus aplikasi akan memudahkan pencabutan akses jika terjadi penyusupan tanpa memengaruhi aplikasi lain. Setelah menetapkan peran IAM yang benar untuk akun layanan, Anda dapat membuat kunci akun layanan JSON, lalu memasang kunci tersebut ke Pod menggunakan Secret Kubernetes.

Menggunakan Otorisasi Biner

Otorisasi Biner adalah layanan di Google Cloud yang menyediakan keamanan supply chain software untuk aplikasi yang berjalan di cloud. Otorisasi Biner berfungsi dengan image yang Anda deploy ke GKE dari Artifact Registry atau registry image container lainnya.

Dengan penerapan Otorisasi Biner, Anda dapat memastikan bahwa proses internal yang menjaga kualitas dan integritas software telah berhasil diselesaikan sebelum aplikasi di-deploy ke lingkungan produksi. Untuk mendapatkan petunjuk tentang cara membuat cluster dengan Otorisasi Biner yang diaktifkan, baca artikel Membuat cluster dalam dokumentasi Otorisasi Biner.

Dengan Validasi berkelanjutan Otorisasi Biner (CV), Anda dapat memastikan bahwa image container yang terkait dengan Pod dipantau secara rutin untuk memastikan kesesuaiannya dengan proses internal Anda yang terus berkembang.

Logging audit

Logging audit memungkinkan administrator menyimpan, membuat kueri, memproses, dan memberi tahu peristiwa yang terjadi di lingkungan GKE Anda. Administrator dapat menggunakan informasi yang dicatat ke dalam log untuk melakukan analisis forensik, pemberitahuan real-time, atau untuk membuat katalog bagaimana fleet cluster GKE digunakan dan oleh siapa.

Secara default, GKE mencatat log Aktivitas Admin. Secara opsional, Anda juga dapat mencatat peristiwa Akses Data ke dalam log, bergantung pada jenis operasi yang ingin diperiksa.

Untuk informasi selengkapnya:

Tindakan keamanan bawaan

GKE menerapkan batasan tertentu pada tindakan yang dapat Anda lakukan terhadap objek sistem di cluster. Saat Anda melakukan operasi seperti menerapkan patch pada workload, webhook izin bernama GKE Warden akan memvalidasi permintaan Anda terhadap serangkaian operasi yang dibatasi dan memutuskan apakah akan mengizinkan permintaan tersebut.

Langkah-langkah keamanan cluster Autopilot

Cluster Autopilot menerapkan beberapa setelan keamanan berdasarkan keahlian kami dan praktik terbaik industri. Untuk mengetahui detailnya, lihat Langkah keamanan di Autopilot.

Langkah-langkah keamanan cluster standar

Cluster Standar secara default lebih permisif daripada cluster Autopilot. Cluster GKE Standard memiliki setelan keamanan berikut:

  • Anda tidak dapat mengupdate ServiceAccount yang digunakan oleh workload sistem yang dikelola GKE, seperti workload di namespace kube-system.
  • Anda tidak dapat mengikat ClusterRole default cluster-admin ke grup system:anonymous, system:unauthenticated, atau system:authenticated.