Keamanan

Halaman ini menjelaskan fitur keamanan yang disertakan dalam GKE di VMware, termasuk setiap lapisan infrastrukturnya, dan cara mengonfigurasi fitur keamanan ini sesuai kebutuhan Anda.

Ringkasan

GKE di VMware menawarkan beberapa fitur untuk membantu mengamankan beban kerja Anda, 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 Anda berikan kepada pengguna dan beban kerja. Anda mungkin perlu melakukan kompromi untuk memungkinkan tingkat fleksibilitas dan keamanan yang tepat.

Autentikasi dan Otorisasi

Anda melakukan autentikasi ke GKE di cluster VMware menggunakan OpenID Connect (OIDC) atau token Akun Layanan Kubernetes melalui Cloud Console.

Untuk mengonfigurasi akses yang lebih terperinci ke resource Kubernetes pada level cluster atau dalam namespace Kubernetes, gunakan Role-Based Access Control (RBAC) Kubernetes. Dengan RBAC, Anda dapat membuat kebijakan mendetail yang menentukan operasi dan resource mana yang ingin Anda izinkan untuk diakses oleh pengguna dan akun layanan. Dengan RBAC, Anda dapat mengontrol akses untuk setiap identitas tervalidasi yang disediakan.

Untuk lebih menyederhanakan dan menyederhanakan strategi autentikasi dan otorisasi Anda untuk Kubernetes Engine, GKE di VMware menonaktifkan Attribute Based Access Control (ABAC) lama.

Keamanan bidang kontrol

Komponen bidang kontrol mencakup server Kubernetes API, penjadwal, pengontrol, dan database dll. tempat konfigurasi Kubernetes Anda disimpan. Sementara di Kubernetes Engine, komponen bidang kontrol Kubernetes dikelola dan dikelola oleh Google, sedangkan administrator lokal mengelola komponen bidang kontrol dalam GKE di VMware.

Pada GKE di VMware, komponen bidang kontrol berjalan dalam jaringan perusahaan Anda. Anda dapat melindungi GKE di server API VMware dengan menggunakan firewall dan kebijakan jaringan perusahaan yang ada. Anda juga dapat menetapkan alamat IP pribadi ke server API dan membatasi akses ke alamat pribadi.

Semua komunikasi di GKE di VMware dilakukan melalui saluran TLS, yang diatur oleh tiga certificate authority (CA): etcd, cluster, dan org:

  • CA etcd mengamankan komunikasi dari server API ke replika etcd serta memproses traffic antara replika etcd. CA ini ditandatangani sendiri.
  • CA cluster mengamankan komunikasi antara server API dan semua klien Kubernetes API internal (kubelets, pengontrol, penjadwal). CA ini ditandatangani sendiri.
  • CA org adalah CA eksternal yang digunakan untuk menyalurkan Kubernetes API kepada pengguna eksternal. Anda mengelola CA ini.

Untuk bidang kontrol admin, kunci disimpan di node bidang kontrol. Untuk cluster pengguna, kunci disimpan sebagai Rahasia Kubernetes di bidang kontrol admin. Server API dikonfigurasi dengan sertifikat yang diberikan pengguna dan ditandatangani oleh CA org. Server API menggunakan Server Name Indication (SNI) untuk menentukan apakah akan menggunakan kunci yang ditandatangani oleh CA cluster atau kunci yang ditandatangani oleh CA organisasi.

Autentikasi cluster di GKE di VMware ditangani oleh token pemilik sertifikat dan akun layanan. Sebagai administrator, Anda melakukan autentikasi ke bidang kontrol menggunakan OIDC, atau dengan sertifikat administratif (yang Anda gunakan untuk pembuatan binding peran awal, atau untuk tujuan darurat).

Rotasi sertifikat ditangani dengan cara berikut:

  • Untuk server API, bidang kontrol, dan node, sertifikat dibuat atau dirotasi pada setiap upgrade.
  • CA dapat dirotasi jarang atau sesuai permintaan.

Keamanan node

GKE di VMware men-deploy workload Anda di instance VMware, yang disertakan ke cluster Anda sebagai node. Bagian berikut menunjukkan cara memanfaatkan fitur keamanan level node yang tersedia bagi Anda di GKE di VMware.

Ubuntu

GKE di VMware menggunakan versi Ubuntu yang dioptimalkan sebagai sistem operasi yang menjalankan bidang kontrol dan node Kubernetes. Ubuntu mencakup serangkaian fitur keamanan modern, dan GKE di VMware mengimplementasikan beberapa fitur peningkatan keamanan untuk cluster, termasuk:

  • Gambar telah dikonfigurasi untuk memenuhi standar PCI DSS, NIST Baseline High, dan DoD Cloud Computing SRG Impact Level 2.
  • Kumpulan paket yang dioptimalkan.
  • Kernel Linux yang disesuaikan Google Cloud.
  • Update keamanan OS otomatis opsional.
  • Akun pengguna terbatas dan login root dinonaktifkan.

Panduan keamanan tambahan tersedia untuk Ubuntu, seperti:

Upgrade node

Anda harus mengupgrade node secara teratur. Dari waktu ke waktu, masalah keamanan di runtime container, Kubernetes itu sendiri, atau sistem operasi node mungkin mengharuskan Anda untuk mengupgrade node dengan lebih mendesak. Saat Anda mengupgrade cluster, software setiap node akan diupgrade ke versi terbarunya.

Mengamankan workload Anda

Dengan Kubernetes, pengguna dapat menyediakan, menskalakan, dan memperbarui beban kerja berbasis container dengan cepat. Bagian ini menjelaskan taktik yang dapat digunakan administrator dan pengguna untuk membatasi kemampuan container yang berjalan agar memengaruhi container lain di cluster, host yang menjalankannya, dan layanan Google Cloud yang diaktifkan dalam project mereka.

Membatasi hak istimewa proses container Pod

Membatasi hak istimewa pada proses dalam container sangat penting untuk keamanan cluster Anda secara keseluruhan. Kubernetes Engine memungkinkan Anda menetapkan opsi terkait keamanan melalui Konteks Keamanan di Pod dan container. Setelan ini memungkinkan Anda mengubah setelan keamanan proses seperti:

  • Pengguna dan grup yang akan dijalankan sebagai.
  • Kemampuan Linux yang tersedia.
  • Eskalasi akses.

GKE default pada sistem operasi node VMware, Ubuntu, menerapkan kebijakan keamanan Docker AppArmor default ke semua container yang dimulai oleh Kubernetes. Anda dapat melihat template profil di GitHub. Di antara hal lainnya, profil ini menyangkal kemampuan berikut pada container:

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

Logging audit

Logging Audit Kubernetes menyediakan cara bagi administrator untuk menyimpan, mengkueri, memproses, dan memberi tahu peristiwa yang terjadi di GKE Anda pada lingkungan VMware. Administrator dapat menggunakan informasi yang dicatat ke dalam log untuk melakukan analisis forensik, pemberitahuan real-time, atau untuk membuat katalog bagaimana fleet cluster Kubernetes Engine digunakan dan oleh siapa.

Secara default, GKE pada aktivitas admin log VMware. Anda juga dapat mencatat peristiwa akses data ke dalam log, bergantung pada jenis operasi yang ingin Anda periksa.

Agen Connect hanya berkomunikasi dengan server API lokal yang berjalan di infrastruktur lokal, dan setiap cluster harus memiliki kumpulan log auditnya sendiri. Semua tindakan yang dilakukan pengguna dari UI melalui Connect dicatat ke dalam log oleh cluster tersebut.

Enkripsi

Jika GKE Anda di cluster dan workload VMware terhubung dengan aman ke layanan Google Cloud melalui Cloud VPN, Anda dapat menggunakan Cloud Key Management Service (Cloud KMS) untuk pengelolaan kunci. Cloud KMS adalah layanan pengelolaan kunci yang dihosting di cloud dan dapat Anda gunakan untuk mengelola kunci kriptografis untuk layanan Anda. Anda dapat membuat, menggunakan, merotasi, dan menghancurkan kunci kriptografis AES256, RSA 2048, RSA 3072, RSA 4096, EC P256, dan EC P384. Cloud KMS terintegrasi dengan Identity and Access Management (IAM) dan Cloud Audit Logging sehingga Anda dapat mengelola izin pada setiap kunci dan memantau penggunaannya. Gunakan Cloud KMS untuk melindungi Rahasia dan data sensitif lainnya yang perlu Anda simpan. Jika tidak, Anda dapat memilih untuk menggunakan salah satu alternatif berikut:

  • Secret Kubernetes
  • Vault Hashicorp
  • Jaringan Thales Luna HSM
  • Modul Keamanan Hardware (HSM) Google Cloud

Secret Kubernetes

Resource Secret Kubernetes menyimpan data sensitif, seperti sandi, token OAuth, dan kunci SSH di cluster Anda. Menyimpan data sensitif di Rahasia lebih aman daripada menyimpannya dalam ConfigMaps teks biasa atau dalam spesifikasi Pod. Dengan menggunakan Secret, Anda dapat mengontrol cara data sensitif digunakan, dan mengurangi risiko pengungkapan data kepada pengguna yang tidak sah.

Vault Hashicorp

Modul Keamanan Hardware