Memilih mekanisme autentikasi yang tepat adalah aspek penting dalam mengamankan klaster Anda. Kubernetes menyediakan beberapa mekanisme bawaan, masing-masing dengan kelebihan dan kekurangannya yang harus dipertimbangkan dengan hati-hati saat memilih mekanisme autentikasi terbaik untuk klaster Anda.
Secara umum, disarankan untuk mengaktifkan sesedikit mungkin mekanisme autentikasi untuk menyederhanakan manajemen pengguna dan mencegah kasus di mana pengguna tetap memiliki akses ke klaster yang tidak lagi diperlukan.
Penting untuk dicatat bahwa Kubernetes tidak memiliki basis data pengguna bawaan di dalam klaster. Sebaliknya, Kubernetes mengambil informasi pengguna dari sistem autentikasi yang dikonfigurasi dan menggunakan informasi tersebut untuk membuat keputusan otorisasi. Oleh karena itu, untuk mengaudit akses pengguna, Anda perlu meninjau kredensial dari setiap sumber autentikasi yang dikonfigurasi.
Untuk klaster produksi dengan banyak pengguna yang mengakses API Kubernetes secara langsung, disarankan untuk menggunakan sumber autentikasi eksternal seperti OIDC. Mekanisme autentikasi internal, seperti sertifikat klien dan token akun layanan yang dijelaskan di bawah ini, tidak cocok untuk kasus penggunaan ini.
Kubernetes memanfaatkan sertifikat klien X.509 untuk komponen sistem, seperti saat kubelet mengautentikasi ke API Server. Meskipun mekanisme ini juga dapat digunakan untuk autentikasi pengguna, mekanisme ini mungkin tidak cocok untuk penggunaan produksi karena beberapa batasan:
O dari sertifikat klien, yang berarti keanggotaan grup pengguna tidak dapat diubah
selama masa berlaku sertifikat.Meskipun Kubernetes memungkinkan Anda memuat kredensial dari berkas token statis yang terletak di disk node control plane, pendekatan ini tidak disarankan untuk server produksi karena beberapa alasan:
Token bootstrap digunakan untuk menghubungkan node ke klaster dan tidak disarankan untuk autentikasi pengguna karena beberapa alasan:
Rahasia akun layanan tersedia sebagai opsi untuk memungkinkan beban kerja yang berjalan di klaster mengautentikasi ke API server. Di Kubernetes < 1.23, ini adalah opsi default, namun, mereka sedang digantikan dengan token API TokenRequest. Meskipun rahasia ini dapat digunakan untuk autentikasi pengguna, mereka umumnya tidak cocok karena beberapa alasan:
API TokenRequest adalah alat yang berguna untuk menghasilkan kredensial jangka pendek untuk autentikasi layanan ke API server atau sistem pihak ketiga. Namun, ini umumnya tidak disarankan untuk autentikasi pengguna karena tidak ada metode pencabutan yang tersedia, dan mendistribusikan kredensial ke pengguna dengan cara yang aman dapat menjadi tantangan.
Saat menggunakan token TokenRequest untuk autentikasi layanan, disarankan untuk menerapkan masa berlaku yang pendek untuk mengurangi dampak token yang disusupi.
Kubernetes mendukung integrasi layanan autentikasi eksternal dengan API Kubernetes menggunakan OpenID Connect (OIDC). Ada berbagai macam perangkat lunak yang dapat digunakan untuk mengintegrasikan Kubernetes dengan penyedia identitas. Namun, saat menggunakan autentikasi OIDC di Kubernetes, penting untuk mempertimbangkan langkah-langkah penguatan berikut:
Autentikasi token Webhook adalah opsi lain untuk mengintegrasikan penyedia autentikasi eksternal ke Kubernetes. Mekanisme ini memungkinkan layanan autentikasi, baik yang berjalan di dalam klaster atau di luar, untuk dihubungi untuk keputusan autentikasi melalui webhook. Penting untuk dicatat bahwa kesesuaian mekanisme ini kemungkinan besar bergantung pada perangkat lunak yang digunakan untuk layanan autentikasi, dan ada beberapa pertimbangan khusus Kubernetes yang harus diperhatikan.
Untuk mengonfigurasi autentikasi Webhook, akses ke sistem file server control plane diperlukan. Ini berarti bahwa hal ini tidak akan memungkinkan dengan Kubernetes yang dikelola kecuali penyedia secara khusus membuatnya tersedia. Selain itu, perangkat lunak apa pun yang diinstal di klaster untuk mendukung akses ini harus diisolasi dari beban kerja umum, karena akan berjalan dengan hak istimewa tinggi.
Opsi lain untuk mengintegrasikan sistem autentikasi eksternal ke Kubernetes adalah dengan menggunakan proxy autentikasi. Dengan mekanisme ini, Kubernetes mengharapkan menerima permintaan dari proxy dengan nilai header tertentu yang ditetapkan, menunjukkan nama pengguna dan keanggotaan grup untuk tujuan otorisasi. Penting untuk dicatat bahwa ada pertimbangan khusus yang harus diperhatikan saat menggunakan mekanisme ini.
Pertama, TLS yang dikonfigurasi dengan aman harus digunakan antara proxy dan API server Kubernetes untuk mengurangi risiko serangan penyadapan atau pengintaian lalu lintas. Ini memastikan bahwa komunikasi antara proxy dan API server Kubernetes aman.
Kedua, penting untuk menyadari bahwa penyerang yang dapat memodifikasi header permintaan mungkin dapat memperoleh akses tidak sah ke sumber daya Kubernetes. Oleh karena itu, penting untuk memastikan bahwa header diamankan dengan baik dan tidak dapat dirusak.