Dokumen ini menjelaskan langkah-langkah keamanan yang disertakan dalam Connect.
Platform hybrid dan multi-cloud yang efektif menghadirkan pengelolaan terpusat, kemampuan observasi, dan akses ke layanan di seluruh lingkungan. GKE Enterprise memberikan pengalaman yang seragam dan komprehensif di seluruh kapabilitas tersebut, apa pun penyedia Kubernetes yang Anda gunakan. Connect adalah agen ringan yang memberikan hal berikut dalam skala ekonomis, dan di berbagai penyedia:
- Pengelolaan multi-cluster dan visibilitas cluster
- Deployment layanan aplikasi dan pengelolaan siklus proses
Dokumen ini membahas hal-hal berikut:
- Bagaimana desain Connect mengutamakan keamanan
- Praktik terbaik untuk deployment Connect Agent
- Cara meningkatkan postur keamanan deployment Kubernetes Anda
Arsitektur Connect
Dengan Connect, pengguna akhir dan layanan Google Cloud dapat 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 tersebut kemudian 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 mungkin juga berasal dari interaksi pengguna langsung dengan Konsol Google Cloud, Gateway Connect, 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 tersebut ke server Kubernetes API. Server Kubernetes API menerapkan kebijakan autentikasi, otorisasi, dan logging audit Kubernetes, serta menampilkan respons. Responsnya 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 Anda.
Menghubungkan dan defense in depth
Defense in depth merupakan bagian penting dari semua tindakan Google Cloud dalam praktik keamanan dan infrastrukturnya. Kami menerapkan pendekatan berlapis pada setiap aspek dalam mengamankan organisasi dan pelanggan kami untuk melindungi data, informasi, dan pengguna yang berharga. Ini adalah prinsip yang sama dengan yang kami gunakan untuk merancang Connect.
Selain strategi dan desain defense in depth Google, Anda harus mengevaluasi konten yang disediakan di sini beserta postur dan standar keamanan. 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 pembanding yang diautentikasi dan diberi otorisasi untuk data tersebut, seperti yang diilustrasikan dalam diagram berikut.
Setiap komponen permintaan Connect menggunakan hal berikut untuk saling mengautentikasi:
- 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 dalam pengiriman, dan hanya diterima oleh peer yang diautentikasi dan diizinkan.
Autentikasi pengguna ke Google Cloud
Saat menggunakan konsol Google Cloud, pengguna 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 Konsol Google Cloud atau API lain dikontrol oleh izin IAM.
Autentikasi service-to-service Google Cloud
Google Cloud menggunakan ALTS untuk autentikasi layanan-ke-layanan internal. ALTS memungkinkan layanan Google Cloud, seperti proxy, untuk membuat koneksi yang diautentikasi dan dilindungi integritas.
Layanan Google Cloud harus diizinkan secara internal untuk menggunakan proxy agar dapat terhubung ke instance Connect jarak jauh karena proxy tersebut menggunakan daftar identitas layanan yang diizinkan untuk membatasi akses.
Mengautentikasi Google Cloud
Agen menggunakan TLS untuk mengautentikasi dan mengenkripsi setiap koneksi. Agen mengautentikasi sertifikat Google Cloud TLS dengan menggunakan serangkaian root certificate yang ada di dalam biner, agar tidak mempercayai sertifikat yang ditambahkan ke penampung agen secara tidak sengaja. 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 setiap respons 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 end-to-end koneksi
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 melakukan autentikasi dengan akun layanan ini, dan meminta untuk menerima permintaan untuk project yang dikonfigurasi.
Google Cloud mengautentikasi kredensial akun layanan, dan juga memeriksa apakah 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 memberi penampung agen sertifikat certificate authority (CA) TLS 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: layanan Google Cloud yang membuat permintaan, dan (jika berlaku) pengguna akhir yang menjadi tujuan pengiriman permintaan tersebut. Dengan kredensial ini, server Kubernetes API dapat memberikan kontrol audit dan otorisasi untuk setiap permintaan.
Autentikasi service-to-agent
Setiap permintaan yang dikirim ke agen menyertakan token berumur singkat yang mengidentifikasi layanan Google Cloud yang mengirim permintaan, seperti yang diilustrasikan dalam diagram berikut.
Token ditandatangani oleh akun layanan Google Cloud yang terkait 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 permintaan tersebut 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 melakukan autentikasi ke server API, seperti yang ditunjukkan dalam diagram berikut.
Kebijakan ini membantu memastikan bahwa kumpulan izin yang sama diterapkan kepada pengguna saat mengakses melalui Connect. Beberapa layanan Google Cloud mengautentikasi ke server API atas nama pengguna. Misalnya, pengguna dapat mengakses Konsol Google Cloud untuk melihat beban kerja di cluster yang terdaftar untuk Perangkat. 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 nonaktif, 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 mengetahui informasi lebih lanjut, lihat Penghapusan data di Google Cloud.
Saat pengguna berinteraksi dengan Konsol Google Cloud, permintaan untuk server Kubernetes API akan dihasilkan. Layanan mengirimkan kredensial pengguna beserta permintaannya melalui Connect. Agen kemudian menyajikan 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 dilakukan untuk permintaan lainnya.
Autentikasi Service-to-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 untuk 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 multicluster ingress dapat otomatis menyinkronkan resource masuk di seluruh cluster. Layanan ini tidak memiliki kredensial yang dapat diotentikasi 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, keduanya memungkinkan permintaan melalui agen untuk melakukan autentikasi sebagai akun layanan Google Cloud.
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 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 tersebut dapat meniru identitas akun layanan Google Cloud. Kemampuan untuk meniru identitas biasanya dikontrol oleh aturan kontrol akses berbasis peran (RBAC), dan dapat terbatas pada identitas tertentu, seperti akun layanan Google Cloud.
Jika agen diotorisasi untuk meniru identitas yang diminta, server API akan melakukan pemeriksaan otorisasi untuk akun layanan Google Cloud, dan menayangkan permintaan tersebut. Log audit untuk permintaan tersebut menyertakan identitas agen dan akun layanan Google Cloud yang ditiru identitasnya.
Keamanan dalam cluster
Agen akhirnya mengirimkan permintaan Kubernetes API ke server Kubernetes API, seperti yang terlihat dalam diagram berikut.
Server Kubernetes API mengautentikasi, memberi otorisasi, dan membuat log audit untuk 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 pelaku lain mendapatkan akses tersebut, dan untuk membantu memastikan bahwa agen hanya mengakses apa yang seharusnya.
Autentikasi Kubernetes
Server Kubernetes API mengautentikasi pengirim setiap permintaan masuk untuk menentukan izin yang akan diterapkan pada tahap otorisasi. Seperti yang dijelaskan sebelumnya, permintaan tersebut menyertakan kredensial pengguna, atau menyertakan kredensial Kubernetes dan header peniruan identitas agen.
Admin cluster tetap memegang kendali 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 akan memeriksa apakah identitas yang diautentikasi diizinkan untuk mengambil 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 tersebut dapat mengakses kredensialnya sendiri (Kubernetes dan Google Cloud), serta kredensial, permintaan, dan respons yang melewatinya. Dengan demikian, agen menempati posisi tepercaya dalam cluster yang terhubung.
Agen ini didesain dengan dasar-dasar keamanan berikut:
- Agen ini ditulis dalam Go, yang menyediakan pengelolaan memori yang dibersihkan sampah memori dan mencegah banyak operasi memori yang tidak aman.
- Agen di-deploy dalam image container distroless. Image agen tidak mencakup shell, libc, atau kode lain yang tidak terkait dengan jalur eksekusi agen.
- Image agen dibuat oleh infrastruktur build bersama milik Google dari kode 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 hasil edit pada sumber agen dapat dilacak kembali ke penulis dan peninjau untuk mengetahui anti-penyangkalan.
Agen berjalan sebagai deployment standar di cluster Kubernetes yang di-deploy pada saat Anda mendaftarkan cluster Anda.
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 penampung agen. Namun, akses 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 mengaktifkan kontrol akses berbasis identitas yang terperinci, Kontrol Layanan VPC memungkinkan keamanan perimeter berbasis konteks yang lebih luas, termasuk mengontrol traffic keluar data di seluruh perimeter. Misalnya, Anda dapat menentukan bahwa hanya project tertentu yang dapat mengakses data BigQuery Anda. Anda dapat menemukan lebih lanjut cara kerja Kontrol Layanan VPC untuk melindungi data Anda di Ringkasan Kontrol Layanan VPC.
Anda dapat menggunakan Kontrol Layanan VPC dengan Connect untuk meningkatkan keamanan data, 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 harus menyiapkan konektivitas pribadi untuk akses ke API yang relevan. Anda dapat mengetahui cara melakukannya di Menyiapkan konektivitas pribadi.