Dokumen ini menjelaskan langkah-langkah keamanan dalam fitur Connect.
Platform hybrid dan multicloud yang efektif memberikan pengelolaan terpusat, kemampuan pengamatan, dan akses ke layanan di seluruh lingkungan. GKE Enterprise memberikan pengalaman yang seragam dan komprehensif di seluruh kemampuan tersebut, terlepas dari 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 memprioritaskan keamanan
- Praktik terbaik untuk deployment Connect Agent
- Cara meningkatkan postur keamanan deployment Kubernetes Anda
Arsitektur Connect
Connect memungkinkan pengguna akhir dan layanan mengakses server Kubernetes API yang tidak berada di internet publik. Google CloudAgen Connect berjalan di cluster Kubernetes (satu agen per cluster), dan terhubung ke proxy Connect. Google Cloud layanan yang perlu berinteraksi dengan cluster Kubernetes terhubung ke proxy, yang meneruskan permintaan ke agen. Selanjutnya, agen meneruskannya ke server Kubernetes API seperti yang digambarkan dalam diagram berikut.
Saat di-deploy, agen akan membuat koneksi TLS 1.2+ persisten ke layanan Google Cloud untuk menunggu permintaan.Layanan Google Cloud , 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.
Layanan Google Cloud mengirimkan permintaan ke proxy. Kemudian, proxy meneruskan permintaan ke agen yang di-deploy yang bertanggung jawab atas cluster, dan terakhir, 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 layanan Google Cloud . 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 untuk semua permintaan, termasuk permintaan melalui Connect. Proses ini memastikan bahwa Anda selalu memiliki kontrol atas akses ke cluster Anda.
Hubungkan dan pertahanan mendalam
Defense-in-depth merupakan bagian penting dari semua yang dilakukan Google Cloud dalam infrastruktur dan praktik keamanannya. Kami menerapkan pendekatan berlapis untuk setiap aspek pengamanan organisasi dan pelanggan kami guna melindungi data, informasi, dan pengguna yang berharga. Ini adalah prinsip yang sama yang kami gunakan untuk mendesain Connect.
Selain strategi dan desain pertahanan mendalam 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 untuk melengkapi praktik terbaik hardening Kubernetes.
Keamanan antar-komponen
Setiap komponen permintaan Connect mengautentikasi peer-nya, dan hanya membagikan data kepada peer yang telah diautentikasi dan diizinkan 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 dalam pengiriman, dan hanya diterima oleh peer yang diautentikasi dan diberi otorisasi.
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 mengautentikasi ke Google Cloud.
Akses ke project melalui konsol Google Cloud atau API lainnya dikontrol oleh izin IAM.
Google Cloud autentikasi antar layanan
Google Cloud menggunakan ALTS untuk autentikasi service-to-service internal. ALTS memungkinkan layanan Google Cloud , seperti proxy, membuat koneksi yang diautentikasi dan dilindungi integritasnya.
LayananGoogle Cloud harus diberi otorisasi secara internal untuk menggunakan proxy guna terhubung ke instance Connect jarak jauh karena proxy menggunakan daftar yang diizinkan untuk identitas layanan guna membatasi akses.
Mengautentikasi Google Cloud
Agen menggunakan TLS untuk mengautentikasi dan mengenkripsi setiap koneksi. Agen mengautentikasi sertifikat TLS menggunakan serangkaian sertifikat root yang dibuat ke dalam biner, untuk menghindari sertifikat yang tidak sengaja dipercaya yang ditambahkan ke penampung agen. Google Cloud Agen hanya menjalankan panggilan API terhadap endpoint yang diautentikasi dengan benar. Proses ini membantu memastikan bahwa sertifikat akun layanan dan permintaan Kubernetes API dikirim olehGoogle Cloud, dan bahwa respons apa pun hanya dikirim ke Google Cloud.
Untuk 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 koneksi end-to-end
antara agen dan Google Cloud tidak terpengaruh.
Mengautentikasi agen
Agen melakukan autentikasi ke Google Cloud dengan menggunakan Fleet Workload Identity Federation. Dengan Fleet Workload Identity Federation, Anda dapat melakukan autentikasi dari beban kerja fleet ke Google Cloud API menggunakan mekanisme autentikasi Kubernetes Google Cloud dan bawaan. Saat ingin melakukan autentikasi ke Google Cloud, agen menukarkan token Akun Layanan Kubernetes-nya dengan token akses yang merepresentasikan identitas beban kerjanya.
Server API Kubernetes
Agen menggunakan library klien Kubernetes untuk membuat koneksi TLS ke server API Kubernetes. Runtime Kubernetes menyediakan sertifikat certificate authority (CA) TLS untuk penampung agen yang digunakan agen untuk mengautentikasi server API.
Server API mengautentikasi setiap permintaan secara terpisah, seperti yang dijelaskan di bagian berikutnya.
Meminta keamanan
Setiap permintaan yang dikirim dari Google Cloud melalui Connect mencakup kredensial yang mengidentifikasi pengirim permintaan: baik layananGoogle Cloud yang membuat permintaan, maupun (jika berlaku) pengguna akhir yang permintaannya dikirim. Kredensial ini memungkinkan server Kubernetes API memberikan kontrol otorisasi dan audit untuk setiap permintaan.
Autentikasi layanan ke agen
Setiap permintaan yang dikirim ke agen mencakup 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 sertifikat Google Cloud menggunakan root CA yang disematkan dalam biner. Proses ini membantu memastikan bahwa API menerima permintaan yang autentik dan tidak diubah dari Google Cloud.
Autentikasi pengguna akhir
Google Cloud layanan yang mengakses cluster atas nama pengguna memerlukan kredensial pengguna tersebut untuk mengautentikasi ke server API, seperti yang diilustrasikan dalam diagram berikut.
Kebijakan ini membantu memastikan bahwa set izin yang sama diterapkan kepada pengguna saat mengakses melalui Connect. Beberapa layananGoogle Cloud melakukan autentikasi ke server API atas nama pengguna. Misalnya, pengguna dapat mengakses konsol Google Cloud untuk melihat beban kerja di cluster yang terdaftar di Fleet. Saat pengguna mengakses layanan ini, mereka memberikan kredensial yang dikenali oleh server Kubernetes API: token apa pun yang didukung oleh server Kubernetes API.
Konsol Google Cloud menyimpan kredensial ini sebagai bagian dari profil pengguna. Kredensial ini dienkripsi saat tidak digunakan, hanya dapat diakses dengan kredensial Google Cloud atau Google Workspace pengguna, dan hanya digunakan untuk koneksi melalui Connect. Kredensial ini tidak dapat didownload lagi. Kredensial 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 konsol Google Cloud , konsol tersebut akan membuat permintaan untuk server Kubernetes API. Layanan mengirimkan kredensial pengguna bersama dengan permintaan melalui Connect. Kemudian, agen mengirimkan permintaan dan kredensial ke server Kubernetes API.
Server Kubernetes API mengautentikasi kredensial pengguna, melakukan otorisasi pada identitas pengguna, membuat peristiwa audit untuk tindakan (jika dikonfigurasi), dan menampilkan hasilnya. Karena kredensial yang disediakan 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 layanan yang mengakses server Kubernetes API di luar konteks pengguna menggunakan peniruan identitas Kubernetes untuk mengautentikasi ke server Kubernetes API. Metode ini memungkinkan server API Kubernetes menyediakan pemeriksaan otorisasi per layanan dan audit logging, seperti yang diilustrasikan dalam diagram berikut.
Layanan di Google Cloud dapat menggunakan Connect di luar konteks pengguna. Misalnya, layanan ingress multicluster dapat menyinkronkan resource ingress secara otomatis di seluruh cluster. Layanan ini tidak memiliki kredensial yang dapat diautentikasi oleh server Kubernetes API: sebagian besar server API tidak dikonfigurasi untuk mengautentikasi kredensial layanan. Google Cloud Namun, server API dapat mendelegasikan hak istimewa autentikasi terbatas ke layanan lain melalui peniruan identitas, dan agen dapat mengautentikasi layanan yang mengirim permintaan melalui Connect. Google Cloud Bersama-sama, keduanya memungkinkan permintaan melalui agen untuk melakukan autentikasi sebagai Google Cloud akun layanan.
Saat layanan Google Cloud mengirim permintaan atas namanya sendiri (bukan dalam konteks pengguna), agen akan menambahkan kredensial Kubernetes-nya sendiri, dan header peniruan identitas Kubernetes yang mengidentifikasi layanan Google Cloud , ke permintaan. Header peniruan identitas mengklaim nama pengguna akun layanan Google Cloud yang diautentikasi oleh agen.
Server Kubernetes API mengautentikasi kredensial agen, dan juga memeriksa apakah agen dapat meniru identitas akun layanan Google Cloud . Kemampuan untuk meniru identitas biasanya dikontrol oleh aturan kontrol akses berbasis peran (RBAC), dan dapat dibatasi untuk identitas tertentu, seperti Google Cloud akun layanan.
Jika agen diizinkan untuk meniru identitas yang diminta, server API kemudian melakukan pemeriksaan otorisasi untuk akun layanan Google Cloud , dan melayani permintaan. Log audit untuk permintaan tersebut mencakup identitas agen dan akun layanan yang ditiru identitasnya. Google Cloud
Keamanan dalam cluster
Pada akhirnya, agen 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 dilayaninya.
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 masuk untuk menentukan izin yang akan diterapkan pada tahap otorisasi. Seperti yang dijelaskan sebelumnya, permintaan menyertakan kredensial pengguna, atau menyertakan kredensial Kubernetes agen dan header peniruan identitas.
Admin cluster tetap memegang 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 melewatinya. Oleh karena itu, agen menempati posisi tepercaya di cluster yang terhubung.
Agen ini didesain dengan dasar-dasar keamanan berikut:
- Agen ditulis dalam Go, yang menyediakan pengelolaan memori dengan pengumpulan sampah, dan mencegah banyak operasi memori tidak aman.
- Agen di-deploy dalam image container distroless. Gambar agen tidak menyertakan shell, libc, atau kode lain yang tidak relevan dengan jalur eksekusi agen.
- Gambar agen dibuat 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 tujuan non-penyangkalan.
Agen berjalan sebagai
deployment
standar di cluster Kubernetes yang di-deploy pada saat Anda mendaftarkan cluster.
Akibatnya, semua opsi dan praktik terbaik yang tersedia untuk memantau dan mengamankan deployment, ReplicaSets, dan pod tersedia untuk agen.
Mekanisme ini dirancang untuk mempersulit kompromi pada container agen. Namun, akses istimewa ke node agen masih dapat membahayakan lingkungan agen; oleh karena itu, administrator harus mengikuti pedoman 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 keluar 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 kerja Kontrol Layanan VPC dalam melindungi data Anda di Ringkasan Kontrol Layanan VPC.
Anda dapat menggunakan Kontrol Layanan VPC dengan Connect untuk keamanan data tambahan, setelah Anda 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 bagian Menyiapkan konektivitas pribadi.