Dokumen ini menjelaskan langkah-langkah keamanan yang ada di Connect.
Platform hybrid dan multi-cloud yang efektif memberikan pengelolaan, kemampuan observasi, dan akses terpusat ke layanan di seluruh lingkungan. GKE Enterprise memberikan pengalaman yang seragam dan komprehensif di seluruh kemampuan tersebut, apa pun penyedia Kubernetes yang Anda gunakan. Connect adalah agen ringan yang menyediakan hal berikut dalam skala ekonomi, dan di seluruh penyedia:
- Pengelolaan multi-cluster dan visibilitas cluster
- Deployment layanan aplikasi dan pengelolaan siklus proses
Dokumen ini membahas hal-hal berikut:
- Cara desain Connect mengutamakan keamanan
- Praktik terbaik untuk deployment Connect Agent
- Cara meningkatkan postur keamanan deployment Kubernetes Anda
Arsitektur Connect
Connect memungkinkan pengguna akhir dan Google Cloud layanan mengakses server Kubernetes API yang tidak berada di internet publik. Connect Agent berjalan di cluster Kubernetes (satu agen per cluster), dan terhubung ke proxy Connect. Google Cloud services yang perlu berinteraksi dengan cluster Kubernetes terhubung ke proxy, yang meneruskan permintaan ke agen. Selanjutnya, agen akan meneruskannya ke server Kubernetes API seperti yang digambarkan dalam diagram berikut.
Saat di-deploy, agen akan membuat koneksi TLS 1.2+ persisten ke Google Cloud untuk menunggu permintaan. Google Cloud services, jika diaktifkan oleh admin, dapat membuat permintaan untuk cluster Kubernetes Anda. Permintaan ini mungkin juga berasal dari interaksi pengguna langsung dengan Google Cloud konsol, Connect Gateway, atau Layanan Google lainnya.
service mengirimkan permintaan ke proxy. Google Cloud Kemudian, proxy meneruskan permintaan ke agen yang di-deploy yang bertanggung jawab atas cluster, dan akhirnya agen meneruskan permintaan ke server Kubernetes API. Server Kubernetes API menerapkan kebijakan autentikasi, otorisasi, dan audit logging Kubernetes, serta menampilkan respons. Respons diteruskan kembali melalui agen dan proxy ke Google Cloud service. Pada setiap langkah dalam proses, komponen melakukan autentikasi dan otorisasi per koneksi dan per permintaan.
Server Kubernetes API menerapkan kebijakan autentikasi, otorisasi, dan audit logging yang sama ke semua permintaan, termasuk permintaan melalui Connect. Proses ini memastikan bahwa Anda selalu memiliki kontrol atas akses ke cluster Anda.
Connect dan defense-in-depth
Defense-in-depth merupakan bagian penting dari semua yang dilakukan dalam infrastruktur dan praktik keamanannya. Google Cloud Kami mengambil pendekatan berlapis untuk setiap aspek pengamanan organisasi dan pelanggan kami guna melindungi data, informasi, dan pengguna yang berharga. Ini adalah prinsip yang sama dengan yang kami gunakan untuk mendesain Connect.
Selain strategi dan desain defense-in-depth Google sendiri, Anda harus mengevaluasi konten yang disediakan di sini bersama dengan postur dan standar keamanan Anda. Bagian ini menjelaskan langkah-langkah tambahan yang dapat Anda lakukan yang melengkapi praktik terbaik hardening Kubernetes.
Keamanan komponen-ke-komponen
Setiap komponen permintaan Connect mengautentikasi peer-nya, dan hanya membagikan data dengan peer yang diautentikasi dan diotorisasi untuk data tersebut, seperti yang diilustrasikan dalam diagram berikut.
Setiap komponen permintaan Connect menggunakan hal berikut untuk mengautentikasi satu sama lain:
- Transport Layer Security (TLS)
- Application Layer Transport Security (ALTS)
- OAuth
Setiap komponen permintaan Connect menggunakan hal berikut untuk mengotorisasi satu sama lain:
- Identity and Access Management (IAM)
- Daftar yang diizinkan
Setiap koneksi antara cluster Kubernetes dan Google Cloud dienkripsi, dan setidaknya satu peer dari setiap koneksi menggunakan autentikasi berbasis sertifikat. Proses ini membantu memastikan bahwa semua kredensial token dienkripsi saat transit, dan hanya diterima oleh peer yang diautentikasi dan diotorisasi.
Autentikasi pengguna ke Google Cloud
Saat menggunakan konsol Google Cloud , pengguna akan melalui alur login Google standar . Google Cloud menyediakan sertifikat TLS yang diautentikasi oleh browser pengguna, dan pengguna login ke akun Google Cloud atau Google Workspace untuk melakukan autentikasi ke Google Cloud.
Akses ke project melalui Google Cloud konsol atau API lainnya dikontrol oleh izin IAM.
Google Cloud Autentikasi layanan-ke-layanan
Google Cloud menggunakan ALTS untuk autentikasi layanan-ke-layanan internal. ALTS allows Google Cloud services, seperti proxy, untuk membuat koneksi terautentikasi yang dilindungi integritasnya.
Google Cloud services harus diotorisasi secara internal untuk menggunakan proxy agar dapat terhubung ke instance Connect jarak jauh karena proxy menggunakan daftar yang diizinkan dari identitas layanan untuk membatasi akses.
Mengautentikasi Google Cloud
Agen menggunakan TLS untuk mengautentikasi dan mengenkripsi setiap koneksi. Agen mengautentikasi Google Cloud sertifikat TLS menggunakan serangkaian sertifikat root yang ada di dalam biner, untuk menghindari kepercayaan yang tidak disengaja terhadap sertifikat yang ditambahkan ke container agen. Agen hanya menjalankan panggilan API terhadap endpoint yang diautentikasi dengan benar. Proses ini membantu memastikan bahwa sertifikat akun layanan dan permintaan Kubernetes API dikirim oleh Google Cloud, dan bahwa respons apa pun hanya dikirim ke Google Cloud.
Untuk mengetahui daftar domain yang berkomunikasi dengan agen selama operasi normal, lihat Memastikan konektivitas jaringan.
Anda dapat mengonfigurasi agen untuk
terhubung ke Google Cloud
melalui proxy HTTP. Dalam konfigurasi ini, agen menggunakan HTTP/1.1
CONNECT terhadap proxy HTTP dan membuat koneksi TLS ke
Google Cloud. Proxy HTTP hanya melihat traffic terenkripsi antara
agen dan Google Cloud. Integritas dan keamanan end-to-end koneksi antara agen dan tidak terpengaruh. Google Cloud
Mengautentikasi agen
Agen melakukan autentikasi ke Google Cloud dengan menggunakan Fleet Workload Identity Federation. Fleet Workload Identity Federation memungkinkan Anda melakukan autentikasi dari workload fleet ke Google Cloud API menggunakan mekanisme autentikasi Kubernetes dan bawaan Google Cloud . Saat agen ingin melakukan autentikasi ke Google Cloud, agen akan menukar token Akun Layanan Kubernetes-nya dengan token akses yang mewakili identitas workload-nya.
Server Kubernetes API
Agen menggunakan library klien Kubernetes untuk membuat koneksi TLS ke server Kubernetes API. Runtime Kubernetes menyediakan sertifikat certificate authority (CA) TLS container agen yang digunakan agen untuk mengautentikasi server API.
Server API mengautentikasi setiap permintaan secara terpisah, seperti yang dijelaskan di bagian berikutnya.
Keamanan permintaan
Setiap permintaan yang dikirim dari Google Cloud melalui Connect menyertakan kredensial yang mengidentifikasi pengirim permintaan: baik Google Cloud layanan yang membuat permintaan, maupun (jika berlaku) pengguna akhir yang permintaannya dikirim. Kredensial ini memungkinkan server Kubernetes API menyediakan kontrol otorisasi dan audit untuk setiap permintaan.
Autentikasi layanan-ke-agen
Setiap permintaan yang dikirim ke agen menyertakan token berumur pendek yang mengidentifikasi Google Cloud layanan yang mengirim permintaan, seperti yang diilustrasikan dalam diagram berikut.
Token ditandatangani oleh akun layanan yang terkait secara eksklusif dengan layanan. Google Cloud Google Cloud Agen mengambil kunci publik akun layanan untuk memvalidasi token. Token ini tidak diteruskan ke server API.
Agen memvalidasi Google Cloud sertifikat menggunakan root CA yang disematkan dalam biner. Proses ini membantu memastikan bahwa agen menerima permintaan yang autentik dan tidak diubah dari Google Cloud.
Autentikasi pengguna akhir
Google Cloud services yang mengakses cluster atas nama pengguna memerlukan kredensial pengguna tersebut untuk melakukan autentikasi ke server API, seperti yang diilustrasikan dalam diagram berikut.
Kebijakan ini membantu memastikan bahwa kumpulan izin yang sama diterapkan kepada pengguna saat mengakses melalui Connect. Beberapa Google Cloud layanan melakukan autentikasi ke server API atas nama pengguna. Misalnya, pengguna dapat mengakses Google Cloud konsol untuk melihat workload di cluster yang terdaftar di Fleet. Saat pengguna mengakses layanan ini, mereka memberikan kredensial yang dikenali oleh server Kubernetes API: salah satu token yang didukung oleh server Kubernetes API.
konsol menyimpan kredensial ini sebagai bagian dari profil pengguna. Google Cloud Kredensial ini dienkripsi saat tidak aktif, hanya dapat diakses dengan kredensial pengguna's Google Cloud atau Google Workspace, dan hanya digunakan untuk koneksi melalui Connect. Kredensial ini tidak dapat didownload lagi. Kredensial akan dihapus saat pengguna logout dari cluster, saat pendaftaran cluster dihapus di Google Cloud, saat project dihapus, atau saat akun pengguna dihapus. Untuk mengetahui informasi selengkapnya, lihat Penghapusan data di Google Cloud.
Saat pengguna berinteraksi dengan Google Cloud konsol, konsol akan membuat permintaan untuk server Kubernetes API. Layanan mengirimkan kredensial pengguna bersama dengan permintaan melalui Connect. Kemudian, agen akan menampilkan permintaan dan kredensial ke server Kubernetes API.
Server Kubernetes API mengautentikasi kredensial pengguna, melakukan otorisasi pada identitas pengguna, menghasilkan peristiwa audit untuk tindakan (jika dikonfigurasi), dan menampilkan hasilnya. Karena kredensial yang diberikan pengguna digunakan untuk mengautentikasi permintaan, server Kubernetes API menerapkan kebijakan otorisasi dan audit yang sama untuk permintaan Connect seperti yang dilakukannya untuk permintaan lainnya.
Autentikasi layanan-ke-Kubernetes
Google Cloud services yang mengakses server Kubernetes API di luar konteks pengguna menggunakan peniruan identitas Kubernetes untuk melakukan autentikasi ke server Kubernetes API. Metode ini memungkinkan server Kubernetes API menyediakan pemeriksaan otorisasi per layanan dan audit logging, seperti yang diilustrasikan dalam diagram berikut.
Services di Google Cloud dapat menggunakan Connect di luar konteks pengguna. Misalnya, layanan ingress multi-cluster dapat otomatis menyinkronkan resource ingress di seluruh cluster. Layanan ini tidak memiliki kredensial yang dapat diautentikasi oleh server Kubernetes API: sebagian besar server API tidak dikonfigurasi untuk mengautentikasi Google Cloud kredensial layanan. Namun, server API dapat mendelegasikan hak istimewa autentikasi terbatas ke layanan lain melalui peniruan identitas, dan agen dapat mengautentikasi Google Cloud services yang mengirim permintaan melalui Connect. Bersama-sama, hal ini memungkinkan permintaan melalui agen untuk melakukan autentikasi sebagai Google Cloud akun layanan.
Saat a Google Cloud service mengirim permintaan atas namanya sendiri (bukan dalam konteks pengguna), agen akan menambahkan kredensial Kubernetes-nya sendiri, dan header peniruan identitas Kubernetes yang mengidentifikasi Google Cloud service, ke permintaan. Header peniruan identitas mengklaim nama pengguna akun Google Cloud layanan yang diautentikasi oleh agen.
Server Kubernetes API mengautentikasi kredensial agen, dan juga memeriksa apakah agen dapat meniru identitas akun Google Cloud layanan. Kemampuan untuk meniru identitas biasanya dikontrol oleh aturan role-based access control (RBAC), dan dapat dibatasi untuk identitas tertentu, seperti Google Cloud akun layanan.
Jika agen diotorisasi untuk meniru identitas yang diminta, server API kemudian akan melakukan pemeriksaan otorisasi untuk akun Google Cloud layanan, dan menayangkan permintaan. Log audit untuk permintaan tersebut mencakup identitas agen dan akun layanan yang ditiru identitasnya. Google Cloud
Keamanan dalam cluster
Agen pada akhirnya mengirimkan permintaan Kubernetes API ke server Kubernetes API, seperti yang diilustrasikan dalam diagram berikut.
Server Kubernetes API mengautentikasi, mengotorisasi, dan mencatat audit permintaan ini, seperti yang dilakukannya untuk semua permintaan lain yang ditayangkannya.
Sebagai proxy untuk permintaan ini, agen memiliki akses ke data sensitif, seperti kredensial, permintaan, dan respons. Kubernetes dan ekosistem Kubernetes menyediakan serangkaian alat untuk mencegah aktor lain mendapatkan akses tersebut, dan untuk membantu memastikan bahwa agen hanya mengakses apa yang seharusnya diakses.
Autentikasi Kubernetes
Server Kubernetes API mengautentikasi pengirim setiap permintaan yang masuk untuk menentukan izin yang akan diterapkan pada tahap otorisasi. Seperti yang dijelaskan sebelumnya, permintaan tersebut menyertakan kredensial pengguna, atau menyertakan kredensial Kubernetes agen dan header peniruan identitas.
Admin cluster tetap memiliki kontrol atas mekanisme autentikasi yang dikenali oleh server Kubernetes API. Admin mungkin dapat mencabut kredensial pengguna, dan dapat mencabut atau mengurangi hak istimewa kredensial agen.
Otorisasi Kubernetes
Server Kubernetes API memeriksa apakah identitas yang diautentikasi diizinkan untuk melakukan tindakan yang diminta pada resource yang diminta.
Admin cluster dapat menggunakan salah satu mekanisme otorisasi Kubernetes untuk mengonfigurasi aturan otorisasi. Connect tidak melakukan pemeriksaan otorisasi apa pun atas nama cluster.
Keamanan agen
Agen memiliki akses ke kredensialnya sendiri (Kubernetes dan Google Cloud), serta kredensial, permintaan, dan respons yang diteruskan melalui agen. Dengan demikian, agen menempati posisi tepercaya di cluster yang terhubung.
Agen didesain dengan dasar keamanan berikut:
- Agen ditulis dalam Go, yang menyediakan pengelolaan memori yang dikumpulkan sampah, dan mencegah banyak operasi memori yang tidak aman.
- Agen di-deploy dalam a tanpa distro image container. Image agen tidak menyertakan shell, libc, atau kode lain yang tidak relevan dengan jalur eksekusi agen.
- Image agen dibangun oleh infrastruktur build bersama Google dari kode yang di-check in. Hanya sistem build ini yang dapat men-deploy image agen ke Container Registry. Google Cloud Developer tidak dapat men-deploy image baru sendiri. Proses ini membantu memastikan bahwa semua pengeditan pada sumber agen dapat dilacak kembali ke penulis dan peninjau untuk non-repudiation.
Agen berjalan sebagai deployment standar
deployment
di cluster Kubernetes yang di-deploy pada saat Anda mendaftarkan cluster.
Oleh karena itu, semua opsi dan praktik terbaik yang tersedia untuk memantau dan mengamankan deployment, ReplicaSets, dan pod tersedia untuk agen.
Mekanisme ini dirancang agar sulit untuk mengganggu container agen. Namun, akses istimewa ke node agen masih dapat mengganggu lingkungan agen. Oleh karena itu, penting bagi administrator untuk mengikuti panduan keamanan Kubernetes standar untuk melindungi infrastruktur cluster.
Keamanan data dengan Kontrol Layanan VPC
Kontrol Layanan VPC memberikan lapisan pertahanan keamanan tambahan untuk Google Cloud layanan yang tidak bergantung pada Identity and Access Management (IAM). Meskipun IAM memungkinkan kontrol akses berbasis identitas yang terperinci, Kontrol Layanan VPC memungkinkan keamanan perimeter berbasis konteks yang lebih luas, termasuk mengontrol egress data di seluruh perimeter—misalnya, Anda dapat menentukan bahwa hanya project tertentu yang dapat mengakses data BigQuery Anda. Anda dapat menemukan informasi selengkapnya tentang cara Kontrol Layanan VPC melindungi data Anda di Ringkasan Kontrol Layanan VPC.
Anda dapat menggunakan Kontrol Layanan VPC dengan Connect untuk keamanan data tambahan, setelah memastikan bahwa layanan yang diperlukan untuk menggunakan Connect dapat diakses dari dalam perimeter layanan yang Anda tentukan.
Jika ingin menggunakan Kontrol Layanan VPC, Anda harus mengaktifkan API berikut:
cloudresourcemanager.googleapis.comgkeconnect.googleapis.comgkehub.googleapis.com
Anda juga perlu menyiapkan konektivitas pribadi untuk akses ke API yang relevan. Anda dapat mengetahui cara melakukannya di Menyiapkan konektivitas pribadi.