Ringkasan keamanan

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

Cluster GKE menawarkan 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 atas 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 enkripsi konfigurasi dan volume. Untuk lebih meminimalkan risiko 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 serangkaian 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 transit. Secara default, GKE di AWS mengenkripsi data di etcd dan volume penyimpanan dalam penyimpanan menggunakan kunci yang dikelola platform AWS.

Cluster GKE di 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 node pool, Anda dapat memberikan 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 berjalan.

Selain itu, semua cluster GKE mengaktifkan Enkripsi Secret Lapisan Aplikasi untuk data sensitif, seperti objek Secret Kubernetes, yang disimpan di 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 dimodifikasi setelah cluster dibuat, sebaiknya Anda menggunakan alias kunci KMS. 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 menyeluruh. Kunci lokal, yang biasanya 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 Anda membuat Secret Kubernetes baru, cluster Anda akan melakukan hal berikut:

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

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

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

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

  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 diakses tanpa mengkueri AWS KMS.

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

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

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

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

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

Rotasi Kunci

Berbeda dengan rotasi sertifikat, rotasi kunci adalah tindakan mengubah materi kriptografi pokok yang terdapat dalam kunci enkripsi kunci (KEK). Rotasi kunci dapat dipicu secara otomatis sebagai bagian dari rotasi terjadwal, atau secara manual, biasanya setelah terjadi insiden keamanan yang menyebabkan kunci mungkin telah 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 ada tindakan manual yang diperlukan.

Untuk mengetahui informasi selengkapnya, lihat Rotasi kunci.

Kepercayaan cluster

Semua komunikasi cluster menggunakan Transport Layer Security (TLS). Setiap cluster disediakan dengan certificate authority (CA) root 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 CA di satu cluster disusupi, CA di cluster lain tidak akan terpengaruh. Semua CA root memiliki periode validitas 30 tahun.

Keamanan node

GKE di AWS men-deploy workload Anda ke node pool instance EC2 AWS. 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 berikut ini:

  • Set paket yang dioptimalkan

  • Google Cloud-tailored Linux kernel

  • Akun pengguna terbatas dan login root dinonaktifkan

Panduan keamanan tambahan tersedia untuk Ubuntu, seperti berikut:

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 cluster dan layanan. Google Cloud

Membatasi hak istimewa proses container Pod

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

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

Sistem operasi node GKE di AWS default, Ubuntu, menggunakan kebijakan keamanan Docker AppArmor default untuk semua container. Anda dapat melihat template profil di GitHub. Di antara berbagai 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 di /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 memerlukan modifikasi mandiri, Anda dapat membatasi izin dengan menginstal Pengontrol Kebijakan atau Pemilah Komunikasi di cluster Anda dan menerapkan batasan, seperti NoUpdateServiceAccount dari library open source Pemilah Komunikasi, yang memberikan beberapa solusi keamanan bermanfaat.

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 workload 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 mencakup penentuan entitas tepercaya dan resmi (pengesah) yang dapat menandatangani gambar, dan mungkin mencakup kriteria lain yang harus dipenuhi gambar agar dianggap aman untuk di-deploy.

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

  3. Kunci pribadi, yang dirahasiakan, digunakan untuk membuat tanda tangan digital (yaitu, serangkaian karakter unik) untuk gambar. Tanda tangan ini berfungsi sebagai tanda persetujuan - tanda ini menunjukkan 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 gambar, biasanya di image registry.

  5. Kunci publik kemudian didaftarkan ke sistem Otorisasi Biner sehingga sistem dapat menggunakan kunci publik untuk verifikasi tanda tangan.

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

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

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

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

Mengisolasi workload pada node pool khusus

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

Isolasi workload menggunakan taint dan toleransi bukanlah jaminan keamanan. Gunakan hanya bersama dengan langkah-langkah pengamanan lainnya yang ditawarkan GKE di AWS.

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

Langkah berikutnya