Halaman ini menjelaskan fitur keamanan yang disertakan dalam Google Distributed Cloud (khusus software) untuk VMware, termasuk setiap lapisan infrastrukturnya, dan cara mengonfigurasi fitur keamanan ini agar sesuai dengan kebutuhan Anda.
Ringkasan
Google Distributed Cloud (khusus software) untuk 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 kepada pengguna dan beban kerja. Anda mungkin perlu melakukan kompromi untuk mendapatkan tingkat fleksibilitas dan keamanan yang tepat.
Autentikasi dan Otorisasi
Anda melakukan autentikasi ke clusters 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. 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 setiap identitas yang divalidasi yang diberikan.
Untuk lebih menyederhanakan dan menyederhanakan strategi autentikasi dan otorisasi untuk Kubernetes Engine, Google Distributed Cloud menonaktifkan Kontrol Akses Berbasis Atribut (ABAC) lama.
Keamanan bidang kontrol
Komponen bidang kontrol mencakup server Kubernetes API, penjadwal, pengontrol, dan database etcd tempat konfigurasi Kubernetes Anda disimpan. Sedangkan di GKE, komponen bidang kontrol Kubernetes dikelola dan dikelola oleh Google, administrator lokal mengelola komponen bidang kontrol di Google Distributed Cloud.
Di Google Distributed Cloud, komponen bidang kontrol berjalan dalam jaringan perusahaan Anda. Anda dapat melindungi server Kubernetes API menggunakan kebijakan dan firewall jaringan perusahaan yang ada. Anda juga dapat menetapkan alamat IP internal ke server API dan membatasi akses ke alamat tersebut.
Semua komunikasi di Google Distributed Cloud 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 antar-replika etcd. CA ini ditandatangani sendiri.
- CA cluster mengamankan komunikasi antara server API dan semua klien Kubernetes API internal (kubelet, pengontrol, penjadwal). CA ini ditandatangani sendiri.
- CA organisasi adalah CA eksternal yang digunakan untuk menayangkan 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 Secret Kubernetes di platform kontrol admin. Server API dikonfigurasi dengan sertifikat yang disediakan pengguna dan ditandatangani oleh CA organisasi. 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 ditangani oleh sertifikat dan token pembawa akun layanan. Sebagai administrator, Anda mengautentikasi ke platform kontrol menggunakan OIDC, atau dengan sertifikat administratif (yang Anda gunakan untuk pembuatan pengikatan 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 jarang dirotasi atau sesuai permintaan.
Keamanan node
Google Distributed Cloud men-deploy workload Anda di instance VMware, yang disertakan ke cluster sebagai node. Bagian berikut menunjukkan cara menggunakan fitur keamanan tingkat node yang tersedia untuk Anda.
Ubuntu
Google Distributed Cloud menggunakan versi Ubuntu yang dioptimalkan sebagai sistem operasi yang akan digunakan untuk menjalankan node dan bidang kontrol Kubernetes. Ubuntu menyertakan beragam fitur keamanan modern, dan Google Distributed Cloud menerapkan beberapa fitur peningkatan keamanan untuk cluster, termasuk:
- Image telah dikonfigurasi sebelumnya 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 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 cepat. 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 oleh administrator dan pengguna untuk membatasi kemampuan penampung yang berjalan untuk memengaruhi penampung lain dalam cluster, host tempat penampung berjalan, 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 untuk dijalankan sebagai.
- Kemampuan Linux yang tersedia.
- Eskalasi akses.
Sistem operasi node default, 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 penampung:
- Menulis ke file langsung di 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.
Logging audit
Logging Audit Kubernetes menyediakan cara bagi administrator untuk menyimpan, membuat kueri, memproses, dan memberi tahu peristiwa yang terjadi di lingkungan Google Distributed Cloud Anda. 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, Google Distributed Cloud mencatat aktivitas admin. Secara opsional, Anda juga dapat mencatat peristiwa akses data ke dalam log, bergantung pada jenis operasi yang ingin diperiksa.
Agen Connect hanya berkomunikasi dengan server API lokal yang berjalan di 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 beban kerja Anda 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 yang memungkinkan Anda 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 masing-masing kunci dan memantau cara penggunaannya. Gunakan Cloud KMS untuk melindungi Secret dan data sensitif lainnya yang perlu Anda simpan. Atau, Anda dapat memilih untuk menggunakan salah satu alternatif berikut:
- Secret Kubernetes
- Hashicorp Vault
- Thales Luna network HSM
- Modul Keamanan Hardware (HSM) Google Cloud
Secret Kubernetes
Resource Secrets Kubernetes menyimpan data sensitif, seperti sandi, token OAuth, dan kunci SSH, di cluster Anda. Menyimpan data sensitif di Secret lebih aman daripada menyimpannya dalam ConfigMaps teks biasa atau dalam spesifikasi Pod. Dengan menggunakan Secret, Anda dapat mengontrol cara penggunaan data sensitif, dan mengurangi risiko paparan data kepada pengguna yang tidak sah.