Keamanan

Halaman ini menjelaskan fitur keamanan yang disertakan dalam Google Distributed Cloud, termasuk setiap lapisan infrastrukturnya, dan cara mengonfigurasi fitur keamanan ini sesuai kebutuhan Anda.

Ringkasan

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

Autentikasi dan Otorisasi

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

Untuk mengonfigurasi akses yang lebih terperinci ke resource Kubernetes di level cluster atau dalam namespace Kubernetes, gunakan Role-Based Access Control (RBAC) Kubernetes. RBAC memungkinkan Anda 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 diberikan.

Untuk lebih menyederhanakan dan menyederhanakan strategi autentikasi dan otorisasi untuk Kubernetes Engine, GKE di VMware menonaktifkan Kontrol Akses Berbasis Atribut (ABAC) lama.

Keamanan bidang kontrol

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

Di GKE di VMware, komponen bidang kontrol berjalan dalam jaringan perusahaan Anda. Anda dapat melindungi GKE di server API VMware menggunakan firewall dan kebijakan jaringan perusahaan yang sudah 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 dan juga 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 pada 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 sertifikat dan token pemilik 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 akan dibuat atau diputar pada setiap upgrade.
  • CA dapat dirotasi jarang atau sesuai permintaan.

Keamanan node

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

Ubuntu

GKE di VMware menggunakan versi Ubuntu yang dioptimalkan sebagai sistem operasi yang akan digunakan untuk menjalankan bidang kontrol dan node Kubernetes. Ubuntu menyertakan serangkaian fitur keamanan modern, dan GKE di VMware menerapkan beberapa fitur peningkatan keamanan untuk cluster, yang meliputi:

  • Gambar telah dikonfigurasi sebelumnya untuk memenuhi standar PCI DSS, NIST Baseline High, dan DoD Cloud Computing SRG Impact Level 2.
  • Paket yang dioptimalkan.
  • Kernel Linux yang disesuaikan dengan 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 rutin. Dari waktu ke waktu, masalah keamanan dalam 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 terbaru.

Mengamankan workload Anda

Dengan Kubernetes, pengguna dapat menyediakan, menskalakan, dan memperbarui beban kerja berbasis container dengan cepat. Bagian ini menjelaskan taktik yang dapat digunakan oleh administrator dan pengguna untuk membatasi kemampuan container yang berjalan guna memengaruhi container lain di cluster, host tempat container dijalankan, 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 dapat Anda gunakan untuk 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 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 {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, mengajukan kueri, memproses, dan memberi tahu peristiwa yang terjadi di lingkungan GKE pada VMware Anda. Administrator dapat menggunakan informasi yang dicatat 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 di VMware membuat log aktivitas admin. Secara opsional, 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 akan dicatat ke dalam log oleh cluster tersebut.

Enkripsi

Jika cluster dan workload GKE di 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 key management service 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 atas setiap kunci dan memantau cara 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
  • Hashicorp Vault
  • Jaringan Thales Luna HSM
  • Modul Keamanan Hardware Google Cloud (HSM)

Secret Kubernetes

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

Hashicorp Vault

Modul Keamanan Hardware