Halaman ini menjelaskan fitur keamanan yang disertakan dalam Google Distributed Cloud (khusus software) untuk VMware, termasuk setiap lapisan infrastrukturnya, dan bagaimana Anda dapat mengkonfigurasi fitur keamanan ini sesuai kebutuhan Anda.
Ringkasan
Google Distributed Cloud (khusus software) untuk VMware menawarkan beberapa fitur untuk membantu mengamankan beban kerja Anda, termasuk konten image container, 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 diberikan kepada pengguna dan workload Anda. Anda mungkin perlu melakukan {i>tradeoff<i} untuk memberikan fleksibilitas dan keamanan yang tepat.
Autentikasi dan Otorisasi
Anda melakukan autentikasi ke cluster menggunakan OpenID Connect (OIDC) atau token Akun Layanan Kubernetes melalui Konsol Cloud.
Untuk mengonfigurasi akses yang lebih terperinci ke resource Kubernetes di tingkat cluster atau dalam namespace Kubernetes, Anda menggunakan Kubernetes Role-Based Access Control (RBAC). RBAC memungkinkan Anda membuat kebijakan terperinci yang mendefinisikan operasi dan sumber daya mana yang Anda izinkan untuk pengguna dan layanan akun yang akan diakses. Dengan RBAC, Anda dapat mengontrol akses untuk semua identitas yang divalidasi yang Anda berikan.
Untuk lebih menyederhanakan dan menyederhanakan otentikasi Anda dan untuk Kubernetes Engine, Google Distributed Cloud akan menonaktifkan Atribut Akses Berbasis Atribut (ABAC) lama.
Keamanan bidang kontrol
Komponen bidang kontrol meliputi server Kubernetes API, scheduler, pengontrol dan database dll. tempat Kubernetes Anda tetap dipertahankan. Sedangkan di GKE, Komponen bidang kontrol Kubernetes dikelola dan dipelihara oleh Google, administrator lokal mengelola komponen bidang kontrol di Google Distributed Cloud.
Di Google Distributed Cloud, komponen bidang kontrol berjalan di dalam jaringan perusahaan. Anda dapat melindungi server Kubernetes API menggunakan kebijakan jaringan dan {i>firewall<i} perusahaan yang ada. Anda juga dapat menetapkan ke server API dan membatasi akses ke alamat tersebut.
Semua komunikasi di Google {i>Distributed Cloud<i} dilakukan melalui saluran TLS, yang diatur oleh tiga certificate authority (CA): dll., cluster, dan org:
- CA {i>etcd<i} mengamankan komunikasi dari server API ke replika {i>etcd<i} dan juga traffic antara replika etcd. CA ini ditandatangani sendiri.
- CA cluster mengamankan komunikasi antara server API dan semua Klien Kubernetes API (kubelet, pengontrol, penjadwal). CA ini ditandatangani sendiri.
- CA org adalah CA eksternal yang digunakan untuk menyalurkan Kubernetes API ke pelanggan. Anda mengelola CA ini.
Untuk bidang kontrol admin, kunci disimpan di bidang kontrol node. Untuk cluster pengguna, kunci tersebut disimpan sebagai Kubernetes Rahasia di bidang kontrol admin. Server API dikonfigurasi dengan sertifikat yang disediakan pengguna yang ditandatangani oleh CA org. Server API menggunakan Nama Server Indikasi (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 pemilik akun layanan token kata. Sebagai administrator, Anda mengotentikasi ke bidang kontrol menggunakan OIDC, atau dengan sertifikat administratif (yang Anda gunakan untuk mengikat peran awal pembuatan, atau untuk tujuan darurat).
Rotasi sertifikat ditangani dengan cara berikut:
- Untuk server API, bidang kontrol, dan node, sertifikat dibuat atau dirotasi di setiap upgrade.
- CA dapat dirotasi jarang atau sesuai permintaan.
Keamanan node
Google Distributed Cloud men-deploy workload Anda di instance VMware, yang yang melekat pada cluster Anda. Bagian berikut menunjukkan cara menggunakan fitur keamanan tingkat {i>node<i} yang tersedia untuk Anda.
Ubuntu
Google Distributed Cloud menggunakan versi Ubuntu yang dioptimalkan sebagai sistem operasi yang digunakan untuk menjalankan node dan bidang kontrol Kubernetes. Ubuntu mencakup rangkaian fitur keamanan modern yang lengkap, dan Google Distributed Cloud menerapkan beberapa fitur peningkat keamanan untuk klaster, yang meliputi:
- Gambar telah dikonfigurasikan sebelumnya agar memenuhi PCI DSS, NIST Baseline High, dan DoD Standar Cloud Computing SRG Impact Level 2.
- Dioptimalkan package.
- Dibuat khusus oleh Google Cloud Kernel Linux.
- Opsional update keamanan OS otomatis.
- 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, keamanan masalah dalam runtime container, Kubernetes itu sendiri, atau sistem operasi node mungkin mengharuskan Anda mengupgrade node secara lebih mendesak. Saat Anda mengupgrade cluster, software setiap node 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 container yang sedang berjalan dalam memengaruhi container lain dalam cluster, host tempat cluster tersebut berjalan, dan layanan Google Cloud 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 melalui Security Context di Pod dan container. Pengaturan ini memungkinkan Anda untuk mengubah pengaturan keamanan proses Anda seperti sebagai:
- Pengguna dan grup yang akan dijalankan sebagai.
- Kemampuan Linux yang tersedia.
- Eskalasi hak istimewa.
Sistem operasi node default, Ubuntu, menerapkan Docker AppArmor default kebijakan keamanan untuk semua container yang dimulai oleh Kubernetes. Anda dapat melihat template profil di GitHub. Di antara hal-hal lain, profil tersebut menolak kemampuan berikut untuk container:
- Menulis ke file secara langsung di direktori ID proses (/proc/).
- Menulis ke file yang tidak ada di {i> /proc/<i}.
- 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, menjalankan kueri, memproses, dan pemberitahuan tentang peristiwa yang terjadi di lingkungan Google Distributed Cloud Anda. Administrator dapat menggunakan informasi yang dicatat untuk melakukan analisis forensik secara {i>real-time<i} pemberitahuan, atau pembuatan katalog tentang cara fleet cluster Kubernetes Engine digunakan dan oleh siapa.
Secara default, Google Distributed Cloud mencatat aktivitas admin. Anda dapat memilih juga mencatat peristiwa akses data, tergantung pada jenis operasi yang yang tertarik untuk diperiksa.
Agen Connect hanya berkomunikasi dengan server API lokal yang menjalankan secara lokal, dan setiap cluster harus memiliki kumpulan log auditnya sendiri. Semua tindakan yang dilakukan pengguna dari UI melalui Connect dicatat oleh .
Enkripsi
Jika cluster dan workload 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 layanan yang dihosting di cloud {i>key management service<i} yang memungkinkan Anda mengelola dan kunci kriptografis untuk layanan Anda. Kamu bisa 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 caranya ini digunakan. Gunakan Cloud KMS untuk melindungi Secret dan data sensitif lainnya yang yang perlu Anda simpan. Jika tidak, Anda dapat memilih untuk menggunakan salah satu opsi berikut alternatif:
- Secret Kubernetes
- Hashicorp Vault
- jaringan Thales Luna HSM
- Modul Keamanan Hardware (HSM) Google Cloud
Secret Kubernetes
Resource Secrets Kubernetes menyimpan data sensitif, seperti sandi, OAuth token, dan kunci SSH, dalam cluster Anda. Menyimpan data sensitif di Secret{i> <i}adalah lebih aman daripada menyimpannya dalam ConfigMaps teks biasa atau di Pod spesifikasi produk. Menggunakan Rahasia memberi Anda kendali atas bagaimana data sensitif digunakan, dan mengurangi risiko paparan data kepada pengguna yang tidak sah.