Hari ini, kami dengan bangga memublikasikan entri blog yang ditulis oleh teman-teman kami di Kudelski Security, penyedia layanan keamanan terkelola. Beberapa minggu yang lalu, Romain Aviolat, Teknisi Cloud dan Keamanan Utama di Kudelski Security mendekati tim Zero Trust kami dengan solusi unik untuk masalah sulit yang didukung oleh Identity-aware Proxy Cloudflare, yang kami sebut Cloudflare Tunnel, untuk memastikan akses aplikasi yang aman di lingkungan kerja jarak jauh.
Kami sangat menikmati belajar tentang solusi mereka sehingga kami ingin memperkuat cerita mereka. Secara khusus, kami menghargai bagaimana teknisi Kudelski Security memanfaatkan fleksibilitas dan skalabilitas teknologi kami sepenuhnya guna mengotomatisasi alur kerja bagi pengguna akhir mereka. Jika Anda tertarik untuk mempelajari lebih lanjut tentang Kudelski Security, lihat pekerjaan mereka di bawah ini atau blog penelitian mereka.
Akses Zero Trust ke Kubernetes
Selama beberapa tahun terakhir, tim teknisi Kudelski Security telah memprioritaskan migrasi infrastruktur kami ke lingkungan multi-cloud. Migrasi cloud internal kami mencerminkan apa yang dikejar klien akhir kami dan telah membekali kami dengan keahlian dan alat guna meningkatkan layanan kami bagi mereka. Selain itu, transisi ini telah memberi kami kesempatan untuk membayangkan kembali pendekatan keamanan kami sendiri dan menerapkan praktik terbaik Zero Trust.
Sejauh ini, salah satu aspek paling menantang dari adopsi Zero Trust kami adalah mengamankan akses ke berbagai bidang kontrol (API) Kubernetes (K8s) kami di berbagai lingkungan cloud. Awalnya, tim infrastruktur kami berusaha untuk mendapatkan visibilitas dan menerapkan kontrol berbasis identitas yang konsisten ke berbagai API yang terkait dengan klaster K8s yang berbeda. Selain itu, saat berinteraksi dengan API ini, pengembang kami sering tidak mengetahui klaster mana yang perlu mereka akses dan bagaimana melakukannya.
Untuk mengatasi pergesekan ini, kami merancang solusi internal yang memanfaatkan Cloudflare untuk mengotomatisasi bagaimana pengembang dapat dengan aman mengautentikasi ke klaster K8 yang berada di cloud publik dan lingkungan di lokasi. Secara khusus, untuk pengembang tertentu, kini kami dapat menampilkan semua layanan K8s yang mereka akses di lingkungan cloud tertentu, mengautentikasi permintaan akses menggunakan aturan Zero Trust Cloudflare, dan membuat koneksi ke klaster tersebut melalui Identity-aware proxy Cloudflare, Cloudflare Tunnel.
Yang terpenting, alat otomatisasi ini telah memungkinkan Kudelski Security sebagai organisasi untuk meningkatkan postur keamanan kami dan meningkatkan pengalaman pengembang kami pada saat yang bersamaan. Kami memperkirakan bahwa alat ini dapat memberi penghematan pada pengembang baru setidaknya dua jam dari waktu yang dihabiskan untuk membaca dokumentasi, mengirimkan tiket layanan TI, dan secara manual menerapkan dan mengonfigurasi berbagai alat yang diperlukan untuk mengakses klaster K8s yang berbeda.
Di blog ini, kami merinci beberapa poin masalah spesifik yang kami tangani, bagaimana kami merancang alat otomatisasi kami, dan bagaimana Cloudflare membantu kami berkembang dalam perjalanan Zero Trust kami dengan cara kerja dari rumah yang ramah.
Tantangan mengamankan lingkungan multi-cloud
Karena Kudelski Security telah memperluas layanan klien dan tim pengembangan internal kami, kami secara inheren telah memperluas jejak aplikasi kami dalam beberapa klaster K8s dan beberapa penyedia cloud. Untuk teknisi dan pengembang infrastruktur kami, API klaster K8s adalah titik masuk penting untuk pemecahan masalah. Kami mengerjakan GitOps dan semua penerapan aplikasi secara otomatis, tetapi kami masih harus selalu terhubung ke klaster untuk menarik log atau men-debug masalah.
Namun, mempertahankan keragaman ini mengakibatkan kompleksitas dan tekanan bagi administrator infrastruktur. Untuk pengguna akhir, infrastruktur yang luas dapat diterjemahkan ke kredensial yang berbeda, alat akses yang berbeda untuk setiap klaster, dan file konfigurasi yang berbeda untuk dilacak.
Pengalaman akses yang kompleks seperti itu dapat membuat pemecahan masalah waktu riil menjadi sangat menyakitkan. Misalnya, teknisi panggilan yang mencoba memahami lingkungan K8s yang tidak dikenal mungkin akan menggali banyak dokumentasi atau dipaksa untuk membangunkan rekan kerja lain untuk mengajukan pertanyaan sederhana. Semua ini rawan kesalahan dan membuang waktu yang berharga.
Pendekatan umum dan tradisional untuk mengamankan akses ke K8s API menghadirkan tantangan yang kami tahu ingin kami hindari. Misalnya, kami merasa bahwa mengekspos API ke internet publik secara inheren akan meningkatkan permukaan serangan kami, itu adalah risiko yang tidak dapat kami tanggung. Selain itu, kami tidak ingin memberikan akses berbasis luas ke API klaster kami melalui jaringan internal dan mengabaikan risiko pergerakan lateral. Seiring pertumbuhan Kudelski, biaya operasional dan kerumitan penerapan VPN di seluruh tenaga kerja kami dan lingkungan cloud yang berbeda akan menimbulkan tantangan penskalaan juga.
Sebaliknya, kami menginginkan pendekatan yang memungkinkan kami mempertahankan lingkungan kecil dan mikro tersegmentasi, domain kegagalan kecil, dan tidak lebih dari satu cara untuk memberikan akses ke layanan.
Memanfaatkan Identity-aware Proxy Cloudflare untuk akses Zero Trust
Untuk melakukan ini, tim teknik Kudelski Security memilih pendekatan yang lebih modern: membuat koneksi antara pengguna dan setiap klaster K8s kami melalui Identity-aware proxy (IAP). IAP fleksibel dalam memberlakukan dan menambahkan layer keamanan tambahan di depan aplikasi kami dengan memverifikasi identitas pengguna saat permintaan akses dibuat. Lebih lanjut, mereka mendukung pendekatan Zero Trust kami dengan membuat koneksi dari pengguna ke aplikasi individual — bukan seluruh jaringan.
Setiap klaster memiliki IAP dan kumpulan kebijakannya sendiri, yang memeriksa identitas (melalui SSO perusahaan kami) dan faktor kontekstual lainnya seperti postur perangkat laptop pengembang. IAP tidak menggantikan mekanisme autentikasi klaster K8s, ia menambahkan yang baru di atasnya, dan berkat federasi identitas dan SSO, proses ini sepenuhnya transparan bagi pengguna akhir kami.
Dalam setup kami, Kudelski Security menggunakan IAP Cloudflare sebagai komponen Cloudflare Access -- solusi ZTNA dan salah satu dari beberapa layanan keamanan yang disatukan oleh platform Zero Trust Cloudflare.
Untuk berbagai aplikasi berbasis web, IAP membantu menciptakan pengalaman tanpa hambatan bagi pengguna akhir yang meminta akses melalui browser. Pengguna mengautentikasi melalui SSO perusahaan atau penyedia identitas mereka sebelum mencapai aplikasi yang aman, sementara IAP bekerja di belakang layar.
Aliran pengguna itu terlihat berbeda untuk aplikasi berbasis CLI karena kami tidak dapat mengarahkan ulang aliran jaringan CLI seperti yang kami lakukan di browser. Dalam kasus kami, teknisi kami ingin menggunakan klien K8s favorit mereka yang berbasis CLI seperti kubectl atau k9s. Ini berarti Cloudflare IAP kami perlu bertindak sebagai proxy SOCKS5 antara klien CLI dan setiap klaster K8s.
Untuk membuat koneksi IAP ini, Cloudflare menyediakan daemon dari sisi server ringan yang disebut cloudflared yang menghubungkan infrastruktur dengan aplikasi. Koneksi terenkripsi ini berjalan di jaringan global Cloudflare di mana kebijakan Zero Trust diterapkan dengan inspeksi sekali jalan.
Namun, tanpa otomatisasi apa pun, tim infrastruktur Kudelski Security perlu mendistribusikan daemon pada perangkat pengguna akhir, memberikan panduan tentang cara menyiapkan koneksi terenkripsi tersebut, dan mengambil langkah-langkah konfigurasi manual dan praktis lainnya serta memeliharanya dari waktu ke waktu. Selain itu, pengembang masih akan kekurangan satu panel visibilitas di berbagai klaster K8s yang perlu mereka akses dalam pekerjaan rutin mereka.
Solusi otomatis kami: k8s-tunnels!
Untuk mengatasi tantangan ini, tim teknik infrastruktur kami mengembangkan alat internal — yang disebut 'k8s-tunnels' — yang menyematkan langkah-langkah konfigurasi kompleks guna mempermudah pengembang kami. Selain itu, alat ini secara otomatis menemukan semua klaster K8s yang dapat diakses oleh pengguna tertentu berdasarkan kebijakan Zero Trust yang dibuat. Untuk mengaktifkan fungsi ini, kami menyematkan SDK dari beberapa penyedia cloud publik utama yang digunakan oleh Kudelski Security. Alat ini juga menyematkan cloudflared daemon_,_ artinya kami hanya perlu mendistribusikan satu alat kepada pengguna kami.
Secara keseluruhan, pengembang yang meluncurkan alat tersebut melalui alur kerja berikut: (kami berasumsi bahwa pengguna sudah memiliki kredensial yang valid jika tidak, alat akan membuka browser di IDP kami untuk mendapatkannya)
1. Pengguna memilih satu atau lebih klaster untuk
2. k8s-tunnel akan secara otomatis membuka koneksi dengan Cloudflare dan mengekspos proxy SOCKS5 lokal di mesin pengembang
3. k8s-tunnel mengubah konfigurasi klien kubernetes lokal pengguna dengan mendorong informasi yang diperlukan untuk melalui proxy SOCKS5 lokal
4. k8s-tunnel mengalihkan konteks klien Kubernetes ke koneksi saat ini
5. Pengguna sekarang dapat menggunakan klien CLI favoritnya untuk mengakses klaster K8s
Seluruh prosesnya sangat mudah dan digunakan setiap hari oleh tim teknik kami. Dan, tentu saja, semua keajaiban ini dimungkinkan melalui mekanisme penemuan otomatis yang kami buat di k8s-tunnels. Setiap kali teknisi baru bergabung dengan tim kami, kami hanya meminta mereka untuk meluncurkan proses penemuan otomatis dan memulainya.
Berikut adalah contoh proses penemuan otomatis yang sedang berjalan.
k8s-tunnels akan terhubung ke berbagai API penyedia cloud kami dan mencantumkan klaster K8s yang dapat diakses pengguna
k8s-tunnels akan mempertahankan file konfigurasi lokal pada mesin pengguna dari klaster tersebut sehingga proses ini tidak dijalankan lebih dari sekali
Peningkatan otomatisasi
Untuk penerapan di lokasi, hal tersebut sedikit lebih rumit karena kami tidak memiliki cara sederhana untuk menyimpan metadata klaster K8 seperti yang kami lakukan dengan tag sumber daya dengan penyedia cloud publik. Kami memutuskan untuk menggunakan Vault sebagai Penyimpanan Nilai Utama untuk meniru tag sumber daya cloud publik untuk lokal. Dengan cara ini kami dapat mencapai penemuan otomatis klaster lokal dengan mengikuti proses yang sama seperti dengan penyedia cloud publik.
Mungkin Anda melihat bahwa di tangkapan layar CLI sebelumnya, pengguna dapat memilih beberapa klaster secara bersamaan! Kami segera menyadari bahwa pengembang kami sering kali perlu mengakses beberapa lingkungan secara bersamaan untuk membandingkan beban kerja yang berjalan dalam produksi dan dalam staging. Jadi, alih-alih membuka dan menutup tunnel setiap kali mereka perlu berpindah klaster, kami merancang alat kami sedemikian rupa sehingga mereka dapat dengan mudah membuka beberapa tunnel secara paralel dalam satu instans k8s-tunnels dan cukup mengganti klaster K8s tujuan di laptop mereka.
Terakhir, tetapi tidak kalah penting, kami juga telah menambahkan dukungan untuk favorit dan notifikasi pada rilisan baru, memanfaatkan Cloudflare Worker, tapi hal tersebut untuk postingan blog lainnya.
Apa selanjutnya
Dalam merancang alat ini, kami telah mengidentifikasi beberapa masalah di dalam pustaka klien Kubernetes saat digunakan bersama dengan beberapa proxy SOCKS5, dan kami bekerja dengan komunitas Kubernetes untuk memperbaiki masalah tersebut, jadi semua orang akan mendapatkan manfaat dari patch tersebut dalam waktu dekat.
Dengan postingan blog ini, kami ingin menyoroti bagaimana mungkin menerapkan keamanan Zero Trust untuk beban kerja kompleks yang berjalan di lingkungan multi-cloud, sekaligus meningkatkan pengalaman pengguna akhir.
Meskipun hari ini kode 'k8s-tunnels' kami terlalu spesifik untuk Kudelski Security, tujuan kami adalah untuk membagikan apa yang telah kami buat kembali ke komunitas Kubernetes, sehingga organisasi lain dan pelanggan Cloudflare dapat mengambil manfaat darinya.