Dokumen ini menjelaskan langkah-langkah keamanan yang terintegrasi dalam Connect.
Platform hybrid dan multi-cloud yang efektif memberikan pengelolaan terpusat, visibilitas, dan akses ke layanan di seluruh lingkungan. GKE Enterprise menyediakan pengalaman yang seragam dan komprehensif di seluruh kemampuan tersebut, apa pun penyedia Kubernetes yang Anda gunakan. Connect adalah agen ringan yang menyediakan hal berikut dengan 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 Agen Connect
- Cara meningkatkan postur keamanan deployment Kubernetes
Arsitektur Connect
Connect memungkinkan pengguna akhir dan layanan Google Cloud mengakses server Kubernetes API yang tidak ada di internet publik. Agen Connect berjalan di cluster Kubernetes (satu agen per cluster), dan terhubung ke proxy Connect. Layanan Google Cloud yang perlu berinteraksi dengan cluster Kubernetes terhubung ke proxy, yang meneruskan permintaan ke agen. Agen, pada gilirannya, meneruskannya ke server Kubernetes API seperti yang ditunjukkan dalam diagram berikut.
Saat di-deploy, agen akan membuat koneksi TLS 1.2+ yang persisten ke Google Cloud untuk menunggu permintaan. Layanan Google Cloud, jika diaktifkan oleh admin, dapat membuat permintaan untuk cluster Kubernetes Anda. Permintaan ini juga dapat berasal dari interaksi pengguna langsung dengan konsol Google Cloud, Connect Gateway, atau Layanan Google lainnya.
Layanan Google Cloud mengirimkan permintaan ke proxy. Proxy kemudian meneruskan permintaan ke agen yang di-deploy dan bertanggung jawab atas cluster, dan akhirnya agen meneruskan permintaan ke server Kubernetes API. Server Kubernetes API menerapkan kebijakan autentikasi, otorisasi, dan logging audit Kubernetes, serta menampilkan respons. Respons tersebut 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 logging audit yang sama untuk semua permintaan, termasuk permintaan melalui Connect. Proses ini memastikan bahwa Anda selalu mengontrol akses ke cluster.
Menghubungkan dan defense-in-depth
Defense-in-depth merupakan bagian intrinsik dari semua hal yang dilakukan Google Cloud dalam infrastruktur dan praktik keamanannya. Kami menggunakan 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 diberikan di sini bersama dengan postur dan standar keamanan Anda. Bagian ini menjelaskan tindakan tambahan yang dapat Anda lakukan untuk 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 diberi otorisasi untuk data tersebut, seperti yang diilustrasikan dalam diagram berikut.
Setiap komponen permintaan Connect menggunakan hal berikut untuk melakukan autentikasi satu sama lain:
- Transport Layer Security (TLS)
- Application Layer Transport Security (ALTS)
- OAuth
Setiap komponen permintaan Connect menggunakan hal berikut untuk memberi otorisasi 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 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.
Autentikasi layanan ke layanan Google Cloud
Google Cloud menggunakan ALTS untuk autentikasi layanan ke layanan internal. ALTS memungkinkan layanan Google Cloud, seperti proxy, membuat koneksi yang diautentikasi dan dilindungi integritasnya.
Layanan Google Cloud harus diotorisasi secara internal untuk menggunakan proxy guna terhubung ke instance Connect jarak jauh karena proxy menggunakan daftar yang diizinkan untuk identitas layanan untuk membatasi akses.
Mengautentikasi Google Cloud
Agen menggunakan TLS untuk mengautentikasi dan mengenkripsi setiap koneksi. Agen mengautentikasi sertifikat TLS Google Cloud menggunakan kumpulan root certificate yang disertakan dalam biner, untuk menghindari kepercayaan yang tidak disengaja terhadap sertifikat yang ditambahkan ke penampung agen. Agen hanya mengeksekusi 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 daftar domain yang dikomunikasikan 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 menggunakan akun layanan Google Cloud yang Anda buat. Saat admin cluster men-deploy agen, mereka memberikan kunci pribadi untuk akun layanan ini dan bertanggung jawab atas privasi kunci. Saat terhubung ke Google Cloud, agen akan mengautentikasi dengan akun layanan ini, dan meminta untuk menerima permintaan untuk project yang dikonfigurasinya.
Google Cloud mengautentikasi kredensial akun layanan, dan juga memeriksa bahwa akun layanan Google Cloud memiliki izin IAM gkehub.endpoints.connect dalam project. Izin ini biasanya diberikan
melalui peran gkehub.connect. Tanpa izin ini, permintaan agen akan ditolak dan tidak dapat menerima permintaan dari Google Cloud.
Server Kubernetes API
Agen menggunakan library klien Kubernetes untuk membuat koneksi TLS ke server Kubernetes API. Runtime Kubernetes menyediakan penampung agen dengan sertifikat certificate authority (CA) TLS yang digunakan agen untuk mengautentikasi server API.
Server API mengautentikasi setiap permintaan secara terpisah, seperti yang dijelaskan di bagian berikut.
Meminta keamanan
Setiap permintaan yang dikirim dari Google Cloud melalui Connect menyertakan kredensial yang mengidentifikasi pengirim permintaan: baik layanan Google Cloud yang membuat permintaan, maupun (jika berlaku) pengguna akhir yang menerima permintaan tersebut. Kredensial ini memungkinkan server Kubernetes API memberikan kontrol otorisasi dan audit untuk setiap permintaan.
Autentikasi layanan ke agen
Setiap permintaan yang dikirim ke agen menyertakan token berumur pendek yang mengidentifikasi layanan Google Cloud yang mengirim permintaan, seperti yang diilustrasikan dalam diagram berikut.
Token ditandatangani oleh akun layanan Google Cloud yang dikaitkan secara eksklusif dengan layanan 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 server menerima permintaan yang autentik dan tidak diubah dari Google Cloud.
Autentikasi pengguna akhir
Layanan Google Cloud 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 kumpulan izin yang sama diterapkan ke pengguna saat mengakses melalui Connect. Beberapa layanan Google 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 server Kubernetes API: token apa pun yang didukung 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 akan dihapus saat pengguna logout dari cluster, saat pendaftaran cluster dihapus di Google Cloud, saat project dihapus, atau saat akun pengguna dihapus. Untuk informasi selengkapnya, lihat Penghapusan data di Google Cloud.
Saat pengguna berinteraksi dengan konsol Google Cloud, konsol akan membuat permintaan untuk server Kubernetes API. Layanan mengirimkan kredensial pengguna bersama dengan permintaan melalui Connect. Agen kemudian 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 melakukan autentikasi permintaan, server Kubernetes API menerapkan kebijakan otorisasi dan audit yang sama untuk permintaan Connect seperti yang dilakukan untuk permintaan lainnya.
Autentikasi layanan ke Kubernetes
Layanan Google Cloud yang mengakses server Kubernetes API di luar konteks pengguna menggunakan peniruan identitas Kubernetes untuk mengautentikasi ke server Kubernetes API. Metode ini memungkinkan server Kubernetes API menyediakan pemeriksaan otorisasi per layanan dan logging audit, seperti yang diilustrasikan dalam diagram berikut.
Layanan 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 kredensial layanan Google Cloud. Namun, server API dapat mendelegasikan hak istimewa autentikasi terbatas ke layanan lain melalui peniruan identitas, dan agen dapat mengautentikasi layanan Google Cloud yang mengirim permintaan melalui Connect. Bersama-sama, hal ini memungkinkan permintaan melalui agen untuk diautentikasi sebagai akun layanan Google Cloud.
Saat layanan Google Cloud mengirim permintaan atas namanya sendiri (bukan dalam konteks pengguna), agen akan menambahkan kredensial Kubernetes, dan header peniruan identitas Kubernetes-nya sendiri yang mengidentifikasi layanan Google Cloud, ke permintaan tersebut. 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 akun layanan Google Cloud.
Jika agen diberi otorisasi untuk meniru identitas yang diminta, server API kemudian akan melakukan pemeriksaan otorisasi untuk akun layanan Google Cloud, dan menayangkan permintaan. Log audit untuk permintaan tersebut mencakup identitas agen dan akun layanan Google Cloud yang ditiru identitasnya.
Keamanan dalam cluster
Agen pada akhirnya mengirimkan permintaan Kubernetes API ke server Kubernetes API, seperti yang diilustrasikan dalam diagram berikut.
Server Kubernetes API mengautentikasi, memberikan otorisasi, dan mencatat permintaan ini ke dalam log audit, seperti yang dilakukan untuk semua permintaan lainnya yang ditayangkan.
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 hal yang seharusnya.
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 menyertakan kredensial pengguna, atau menyertakan kredensial Kubernetes dan header peniruan identitas agen.
Admin cluster tetap mengontrol 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. Dengan demikian, agen menempati posisi tepercaya di cluster yang terhubung.
Agen dirancang dengan dasar-dasar keamanan berikut:
- Agen ditulis dalam Go, yang menyediakan pengelolaan memori yang dikumpulkan sampah, dan mencegah banyak operasi memori tidak aman.
- Agen di-deploy dalam image container distroless. Image agen tidak menyertakan shell, libc, atau kode lain yang tidak relevan dengan jalur eksekusi agen.
- Image 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. Developer Google Cloud 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-penolakan.
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 penyusupan ke penampung agen. Namun, akses dengan hak istimewa ke node agen masih dapat membahayakan lingkungan agen; oleh karena itu, administrator harus mengikuti panduan keamanan Kubernetes standar untuk melindungi infrastruktur cluster.
Keamanan data dengan Kontrol Layanan VPC
Kontrol Layanan VPC memberikan lapisan pertahanan keamanan tambahan untuk layanan Google Cloud 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 untuk 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 ditentukan.
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 mengakses API yang relevan. Anda dapat mengetahui cara melakukannya di Menyiapkan konektivitas pribadi.