Ringkasan Keamanan

Halaman ini menjelaskan arsitektur keamanan GKE di AWS, termasuk enkripsi dan konfigurasi node.

Cluster GKE menawarkan berbagai fitur untuk membantu mengamankan workload Anda, termasuk konten image container, runtime container, jaringan cluster, dan akses ke server API cluster.

Saat menggunakan cluster GKE, Anda setuju untuk memikul tanggung jawab tertentu untuk cluster Anda. Untuk mengetahui informasi selengkapnya, lihat tanggung jawab bersama cluster GKE.

Enkripsi AWS KMS

GKE di AWS menggunakan kunci simetris AWS Key Management Service (KMS) yang dikelola pelanggan untuk mengenkripsi:

Untuk lingkungan produksi, sebaiknya gunakan kunci yang berbeda untuk konfigurasi dan enkripsi volume. Untuk meminimalkan risiko lebih lanjut jika kunci disusupi, Anda juga dapat membuat kunci yang berbeda untuk setiap hal berikut:

Untuk keamanan tambahan, Anda dapat membuat kebijakan kunci AWS KMS yang hanya menetapkan sekumpulan izin minimum yang diperlukan. Untuk mengetahui informasi selengkapnya, lihat Membuat kunci KMS dengan izin tertentu.

Enkripsi data dalam penyimpanan

Enkripsi data dalam penyimpanan adalah enkripsi data yang disimpan, yang berbeda dengan data dalam pengiriman. Secara default, GKE di AWS mengenkripsi data dalam dll. dan volume penyimpanan dalam penyimpanan menggunakan kunci yang dikelola platform AWS.

GKE pada cluster AWS menyimpan data dalam volume AWS Elastic Block Storage (EBS). Volume EBS ini selalu dienkripsi dalam penyimpanan dengan kunci AWS Key Management System (AWS KMS). Saat membuat cluster dan kumpulan node, Anda dapat menyediakan Kunci KMS yang Dikelola Pelanggan (CMK) untuk mengenkripsi volume EBS yang mendasarinya. Jika Anda tidak menentukan kunci, AWS akan menggunakan kunci yang dikelola AWS default dalam region AWS tempat cluster dijalankan.

Selain itu, semua cluster GKE mengaktifkan Enkripsi Secret lapisan Aplikasi untuk data sensitif, seperti objek Secret Kubernetes, yang disimpan dalam etcd. Meskipun penyerang mendapatkan akses ke volume dasar tempat data etcd disimpan, data ini dienkripsi.

Saat membuat cluster, Anda harus meneruskan kunci AWS KMS ke kolom --database-encryption-kms-key-arn. Kunci ini digunakan untuk enkripsi envelope data aplikasi. Karena kolom resource ini tidak dapat diubah dan tidak dapat diubah setelah cluster dibuat, sebaiknya gunakan alias kunci KKM. Anda dapat menggunakan alias kunci untuk merotasi kunci yang digunakan untuk enkripsi dalam penyimpanan selama siklus proses cluster.

Cara kerja enkripsi tingkat aplikasi

Kubernetes menawarkan enkripsi tingkat aplikasi dengan teknik yang dikenal sebagai enkripsi envelope. Kunci lokal, yang biasa disebut kunci enkripsi data (DEK), digunakan untuk mengenkripsi Secret. DEK itu sendiri kemudian dienkripsi dengan kunci kedua yang disebut kunci enkripsi kunci (KEK). KEK tidak disimpan oleh Kubernetes. Saat membuat Secret Kubernetes baru, cluster Anda akan melakukan hal-hal berikut:

  1. Server Kubernetes API menghasilkan DEK unik untuk Secret tersebut menggunakan generator angka acak.

  2. Server Kubernetes API mengenkripsi Secret secara lokal dengan DEK.

  3. Server Kubernetes API mengirimkan DEK ke AWS KMS untuk enkripsi.

  4. AWS KMS menggunakan KEK yang telah dibuat sebelumnya untuk mengenkripsi DEK dan menampilkan DEK terenkripsi ke plugin AWS KMS server Kubernetes.

  5. Server Kubernetes API menyimpan Secret terenkripsi dan DEK terenkripsi ke etcd. DEK teks biasa tidak disimpan ke disk.

  6. Server Kubernetes API membuat entri cache dalam memori untuk memetakan DEK terenkripsi ke DEK teks biasa. Hal ini memungkinkan Server API mendekripsi Secret yang baru saja diakses tanpa mengkueri KMS AWS.

Saat klien meminta Secret dari server Kubernetes API, inilah yang akan terjadi:

  1. Server Kubernetes API mengambil Secret dan DEK terenkripsi yang dienkripsi dari etcd.

  2. Server Kubernetes API memeriksa cache untuk entri peta yang ada dan, jika ditemukan, akan mendekripsi Secret tersebut dengan entri peta tersebut.

  3. Jika tidak ada entri cache yang cocok, server API akan mengirimkan DEK ke AWS KMS untuk didekripsi menggunakan KEK. DEK yang didekripsi kemudian digunakan untuk mendekripsi Secret tersebut.

  4. Terakhir, server Kubernetes API akan menampilkan Secret yang didekripsi kepada klien.

Rotasi Kunci

Berbeda dengan rotasi sertifikat, rotasi kunci merupakan tindakan mengubah materi kriptografi dasar yang terdapat dalam kunci enkripsi kunci (KEK). Pemicuan ini dapat dipicu secara otomatis sebagai bagian dari rotasi terjadwal, atau secara manual, biasanya setelah terjadi insiden keamanan saat kunci disusupi. Rotasi kunci hanya mengganti satu kolom dalam kunci yang berisi data kunci enkripsi/dekripsi mentah.

Rotasi Kunci KMS

AWS KMS mendukung rotasi otomatis kunci KMS. Jika diaktifkan, AWS akan otomatis membuat materi kunci kriptografis baru untuk kunci Anda setahun sekali. Tidak perlu tindakan manual.

Untuk mengetahui informasi selengkapnya, lihat Rotasi kunci.

Kepercayaan cluster

Semua komunikasi cluster menggunakan Transport Layer Security (TLS). Setiap cluster disediakan dengan root certificate authority (CA) utama yang ditandatangani sendiri berikut:

  • CA root cluster digunakan untuk memvalidasi permintaan yang dikirim ke server API.
  • CA root etcd digunakan untuk memvalidasi permintaan yang dikirim ke replika etcd.

Setiap cluster memiliki CA root yang unik. Jika satu CA cluster disusupi, tidak ada CA cluster lain yang akan terpengaruh. Semua root CA memiliki masa berlaku selama 30 tahun.

Keamanan node

GKE di AWS men-deploy workload Anda ke node pool instance AWS EC2. Bagian berikut menjelaskan fitur keamanan node.

Ubuntu

Node Anda menjalankan versi OS Ubuntu yang dioptimalkan untuk menjalankan bidang kontrol dan node Kubernetes. Untuk mengetahui informasi selengkapnya, lihat fitur keamanan dalam dokumentasi Ubuntu.

Cluster GKE menerapkan beberapa fitur keamanan, termasuk yang berikut ini:

  • Kumpulan paket yang dioptimalkan

  • Kernel Linux yang disesuaikan oleh Google Cloud

  • Akun pengguna terbatas dan login root dinonaktifkan

Panduan keamanan tambahan tersedia untuk Ubuntu, seperti berikut ini:

Mengamankan workload Anda

Dengan Kubernetes, pengguna dapat menyediakan, menskalakan, dan memperbarui beban kerja berbasis container dengan cepat. Bagian ini menjelaskan taktik yang dapat Anda gunakan untuk membatasi efek samping dari menjalankan container di layanan cluster dan Google Cloud.

Membatasi hak istimewa proses penampung Pod

Membatasi hak istimewa pada proses dalam container penting untuk keamanan cluster Anda. Anda dapat menetapkan opsi terkait keamanan dengan konteks keamanan. Setelan ini memungkinkan Anda mengubah setelan keamanan proses seperti berikut:

  • Pengguna dan grup yang menjalankan proses
  • Kemampuan Linux yang tersedia
  • Eskalasi akses

GKE default pada sistem operasi node AWS, Ubuntu, menggunakan kebijakan keamanan AppArmor Docker default untuk semua container. Anda dapat melihat template profil di GitHub. Di antara hal lainnya, profil ini menolak kemampuan berikut untuk container:

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

Membatasi kemampuan workload dalam modifikasi mandiri

Workload Kubernetes tertentu, terutama workload sistem, memiliki izin untuk menjalankan modifikasi mandiri Sebagai contoh, beberapa workload melakukan penskalaan otomatis secara vertikal. Meskipun berguna, ini akan memungkinkan penyerang yang telah menyusupi node untuk menjelajahi cluster lebih dalam lagi. Misalnya, penyerang dapat membuat workload pada node melakukan modifikasi mandiri untuk dijalankan sebagai akun layanan dengan hak istimewa yang berada di namespace yang sama.

Idealnya, workload seharusnya sejak awal tidak diizinkan untuk melakukan modifikasi mandiri. Jika modifikasi mandiri diperlukan, Anda dapat membatasi izin dengan menginstal Pengontrol Kebijakan atau Gatekeeper di cluster dan menerapkan batasan, seperti NoUpdateServiceAccount dari library open source Gatekeeper yang menyediakan beberapa kebijakan keamanan yang berguna.

Saat Anda men-deploy kebijakan, biasanya Anda perlu mengizinkan pengontrol yang mengelola siklus proses cluster untuk mengabaikan kebijakan tersebut. Hal ini diperlukan agar pengontrol dapat membuat perubahan pada cluster, seperti menerapkan upgrade cluster. Misalnya, jika Anda men-deploy kebijakan NoUpdateServiceAccount di GKE di AWS, Anda harus menetapkan parameter berikut di Constraint:

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

Ganti PROJECT_NUMBER dengan nomor (bukan ID) project yang menghosting cluster.

Menggunakan Otorisasi Biner

Cara lain untuk mengamankan beban kerja Anda adalah dengan mengaktifkan Otorisasi Biner. Otorisasi Biner adalah fitur keamanan yang memastikan hanya image container tepercaya yang di-deploy di cluster GKE.

Berikut cara kerja prosesnya:

  1. Administrator membuat kebijakan yang menentukan persyaratan untuk men-deploy image. Hal ini termasuk menentukan entity tepercaya dan resmi (attestor) yang dapat menandatangani image, dan mungkin mencakup kriteria lain yang harus dipenuhi oleh image agar dianggap aman untuk deployment.

  2. Attestor (misalnya, developer atau sistem otomatis) menggunakan algoritma kriptografi untuk menghasilkan pasangan kunci (kunci pribadi dan publik).

  3. Kunci pribadi yang dirahasiakan digunakan untuk menghasilkan tanda tangan digital (yaitu, serangkaian karakter unik) untuk gambar. Tanda tangan ini berfungsi sebagai segel persetujuan - tanda bahwa gambar telah lulus semua pemeriksaan dan validasi yang diperlukan.

  4. Tanda tangan digital kemudian 'dilampirkan' ke gambar. Dengan kata lain, tanda tangan disimpan dalam metadata image, biasanya dalam registry image.

  5. Kunci publik ini kemudian didaftarkan dengan sistem Otorisasi Biner agar sistem dapat menggunakan kunci publik tersebut untuk verifikasi tanda tangan.

  6. Saat permintaan untuk men-deploy container dibuat, sistem Otorisasi Biner mengambil tanda tangan digital yang dilampirkan ke image dalam registry.

  7. Sistem Otorisasi Biner menggunakan kunci publik terdaftar untuk memverifikasi tanda tangan digital yang dilampirkan pada image. Alat ini juga memeriksa apakah gambar memenuhi semua kriteria lain yang ditentukan dalam kebijakan. Jika tanda tangan digital dapat berhasil diverifikasi menggunakan kunci publik dan data image, serta image memenuhi semua kriteria lain yang ditentukan dalam kebijakan, sistem Otorisasi Biner memungkinkan container di-deploy. Jika tanda tangan digital tidak berhasil diverifikasi menggunakan kunci publik dan data image, atau jika image tidak memenuhi kriteria lain yang ditetapkan dalam kebijakan, sistem Otorisasi Biner akan menolak deployment container.

Untuk informasi selengkapnya tentang cara kerja Otorisasi Biner, lihat Ringkasan Otorisasi Biner.

Untuk mengaktifkan Otorisasi Biner pada cluster yang ada atau saat membuat cluster, lihat Cara mengaktifkan Otorisasi Biner.

Mengisolasi workload di node pool khusus

Anda dapat menggunakan taint dan toleransi Kubernetes untuk menentukan node pool tertentu guna menjalankan jenis workload tertentu. Misalnya, Anda dapat memberi tahu GKE di AWS untuk menjadwalkan workload pengguna dari sebagian besar workload yang dikelola sistem, atau menempatkan workload dengan tingkat kepercayaan yang berbeda di kumpulan node yang berbeda.

Isolasi workload menggunakan taint dan toleransi bukanlah tindakan keamanan yang dijamin. Hanya gunakan ini bersama tindakan hardening lainnya yang ditawarkan GKE di AWS.

Untuk mempelajari lebih lanjut, lihat Mengisolasi workload di node pool khusus

Langkah selanjutnya