This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Keamanan

Konsep-konsep untuk menjaga cloud-native workload tetap aman.

Bagian dokumentasi Kubernetes ini memiliki tujuan untuk membantu anda menjalankan workloads lebih aman, dan aspek-aspek mendasar dalam menjaga klaster Kubernetes tetap aman.

Kubernetes berbasiskan arsitektur cloud-native dan mengambil saran dari CNCF mengenai praktik yang baik dari cloud native information security.

Baca Cloud Native Security and Kubernetes untuk konteks yang lebih luas mengenai bagaimana cara mengamankan klaster anda dan aplikasi yang berjalan di atasnya.

Mekanisme keamanan Kubernetes

Proteksi control plane

Kunci penting pada apapun varian klaster Kubernetes adalah kontrol akses ke Kubernetes API.

Kubernetes menyarankan anda untuk mengkonfigurasi dan menggunakan TLS dalam menyediakan enkripsi data saat transit di dalam control plane, dan di antara control plane dengan client. Anda juga bisa mengaktifkan encryption at rest untuk data yang tersimpan di dalam Kubernetes control plane; hal ini terpisah dari menggunanakan encryption at rest untuk data anda di workload.

Secrets

Secret API menyediakan perlindungan dasar untuk variabel konfigurasi yang konfidensial.

Perlindungan Workload

Terapkan Pod security standards untuk memastikan Pods dan containers terisolasi dengan baik. Anda juga dapat menggunakan RuntimeClasses untuk mendefinisikan isolasi custom jika dibutuhkan.

Network policies memungkinkan anda mengendalikan trafik jaringan di antara Pods, atau antara Pods dengan jaringan di luar klaster.

Anda dapat men-deploy security controls dari ekosistem yang lebih besar untuk mengimplementasikan kontrol pencegahan atau pendeteksian di sekitar Pods, kontainer dan images yang berjalan.

Audit

Kubernetes audit logging menyediakan sebuah set catatan yang berurutan terkait dengan keamanan, mendokumentasikan urutan aktivitas dalam suatu cluster. Aktivitas cluster audit dihasilkan oleh pengguna, aplikasi yang menggunakan Kubernetes API dan control plane.

Keamanan penyedia cloud

Jika anda menjalankan klaster Kubernetes pada perangkat keras anda sendiri atau pada penyedia layanan komputasi awan, silakan kunjungi halaman dokumentasi untuk melihat saran/tips dalam keamanan. Berikut ini beberapa tautan ke halaman dokumentasi keamanan dari beberapa penyedia jasa komputasi awan:

Keamanan cloud provider
Penyedia IaaS Tautan
Alibaba Cloud https://www.alibabacloud.com/trust-center
Amazon Web Services https://aws.amazon.com/security
Google Cloud Platform https://cloud.google.com/security
Huawei Cloud https://www.huaweicloud.com/intl/en-us/securecenter/overallsafety
IBM Cloud https://www.ibm.com/cloud/security
Microsoft Azure https://docs.microsoft.com/en-us/azure/security/azure-security
Oracle Cloud Infrastructure https://www.oracle.com/security
Tencent Cloud https://www.tencentcloud.com/solutions/data-security-and-information-protection
VMware vSphere https://www.vmware.com/solutions/security/hardening-guides

Policies

Anda dapat mendefinisikan security policies menggunakan mekanisme Kubernetes-native seperti NetworkPolicy (kontrol deklaratif atas network packet filtering) atau ValidatingAdmissionPolicy (larangan deklaratif atas perubahan apa yang bisa dibuat seseorang menggunakan Kubernetes API).

Bagaimanapun juga, anda dapat mengandalkan dari implementasi policy dari ekosistem yang lebih besar di sekitar Kubernetes. Kubernetes menyediakan mekanisme ekstensi untuk membiarkan ekosistem proyek tersebut mengimplementasikan policy controls mereka pada peninjauan kode sumber, persetujuan image container, akses kontrol API, jaringan dan lain-lain.

Untuk informasi lebih lanjut mengenai mekanisme policy dan Kubernetes, silakan baca Policies.

Selanjutnya

Pelajari lebih lanjut topik terkait keamanan Kubernetes:

Pelajari konteks:

Ambil sertifikasi:

Baca lebih lanjut dalam bagian ini:

1 - Ikhtisar Keamanan Cloud Native

Keamanan Kubernetes (dan keamanan secara umum) adalah sebuah topik sangat luas yang memiliki banyak bagian yang sangat berkaitan satu sama lain. Pada masa sekarang ini di mana perangkat lunak open source telah diintegrasi ke dalam banyak sistem yang membantu berjalannya aplikasi web, ada beberapa konsep menyeluruh yang dapat membantu intuisimu untuk berpikir tentang konsep keamanan secara menyeluruh. Panduan ini akan mendefinisikan sebuah cara/model berpikir untuk beberapa konsep umum mengenai Keamanan Cloud Native. Cara berpikir ini sepenuhnya subjektif dan kamu sebaiknya hanya menggunakannya apabila ini membantumu berpikir tentang di mana harus mengamankan stack perangkat lunakmu.

4C pada Keamanan Cloud Native

Mari memulainya dengan sebuah diagram yang dapat membantumu mengerti bagaimana berpikir tentang keamanan dalam bentuk beberapa lapisan.

The 4C's of Cloud Native Security

Seperti yang dapat kamu lihat dari gambar di atas, setiap dari 4C tersebut bergantung pada keamanan dari kotak yang lebih besar di mana mereka berada. Hampir tidak mungkin untuk mengamankan sistem terhadap standar-standar keamanan yang buruk pada Cloud, Container, dan Code hanya dengan menangani keamanan pada lapisan kode. Akan tetapi, apabila semua area tersebut ditangani dengan baik, maka menambahkan keamanan ke dalam kode kamu akan memperkuat landasan yang sudah kuat. Area-area yang menjadi perhatian ini akan dideskripsikan lebih mendalam di bawah.

Cloud

Dalam banyak hal, Cloud (atau server-server co-located, atau pusat data/data center korporat) adalah trusted computing base (basis komputasi yang dipercaya) dari sebuah klaster Kubernetes. Jika komponen-komponen tersebut rentan secara keamanan (atau dikonfigurasi dengan cara yang rentan), maka sesungguhnya tidak ada cara untuk menjamin keamanan dari komponen-komponen apa pun yang dibangun di atas basis komputasi ini. Memberikan rekomendasi untuk keamanan cloud berada di luar lingkup panduan ini, karena setiap penyedia layanan cloud dan beban kerja pada dasarnya berbeda-beda. Berikut beberapa tautan menuju beberapa dokumentasi penyedia layanan cloud yang populer untuk keamanan maupun untuk memberikan panduan umum untuk mengamankan infrastruktur yang menjadi basis sebuah klaster Kubernetes.

Tabel Keamanan Penyedia Layanan Cloud

IaaS Provider Link
Alibaba Cloud https://www.alibabacloud.com/trust-center
Amazon Web Services https://aws.amazon.com/security/
Google Cloud Platform https://cloud.google.com/security/
Huawei Cloud https://www.huaweicloud.com/intl/id-id/securecenter/overallsafety
IBM Cloud https://www.ibm.com/cloud/security
Microsoft Azure https://docs.microsoft.com/en-us/azure/security/azure-security
Oracle Cloud Infrastructure https://www.oracle.com/security/
VMWare VSphere https://www.vmware.com/solutions/security/hardening-guides

Jika kamu mengoperasikan perangkat keras kamu sendiri, atau penyedia layanan cloud yang berbeda, kamu perlu merujuk pada dokumentasi penyedia layanan cloud yang kamu pakai untuk praktik keamanan terbaik.

Tabel Panduan Umum Infrastruktur

Area yang Menjadi Perhatian untuk Infrastruktur Kubernetes Rekomendasi
Akses Jaringan terhadap API Server (Master-master) Secara Ideal, semua akses terhadap Master-master Kubernetes tidak diizinkan secara publik pada internet, dan dikontrol oleh daftar kendali akses (network ACL) yang dibatasi untuk kumpulan alamat IP yang dibutuhkan untuk mengelola klaster.
Akses Jaringan terhadap Node-node (Server-server Worker) Node-node harus dikonfigurasikan untuk hanya menerima koneksi-koneksi (melalui daftar kendali akses) dari Master-master pada porta-porta (port) yang telah ditentukan, dan menerima koneksi-koneksi dari Service-service Kubernetes dengan tipe NodePort dan LoadBalancer. Apabila memungkinkan, Node-node tersebut sebaiknya tidak diekspos pada internet publik sama sekali.
Akses Kubernetes terhadap API Penyedia Layanan Cloud Setiap penyedia layanan cloud perlu memberikan kumpulan izin yang berbeda-beda untuk Master-master dan Node-node Kubernetes, sehingga rekomendasi ini sifatnya lebih umum. Praktik terbaiknya adalah untuk memberikan klaster akses terhadap penyedia layanan cloud yang mengikuti principle of least privilege (prinsip hak istimewa paling sedikit) untuk sumber daya yang klaster tersebut perlukan untuk dikelola. Sebuah contoh untuk Kops di AWS dapat ditemukan di sini: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles
Akses terhadap etcd Akses terhadap etcd (tempat penyimpanan data Kubernetes) harus dibatasi hanya untuk Master-master saja. Bergantung pada konfigurasimu, kamu sebaiknya juga mengusahakan koneksi etcd menggunakan TLS. Informasi lebih lanjut dapat ditemukan di sini: https://github.com/etcd-io/etcd/tree/master/Documentation#security
Enkripsi etcd Di mana pun kita dapat melakukannya, mengenkripsi semua data saat diam (at rest) pada semua drive, dan sejak etcd menyimpan keadaan seluruh klaster (termasuk Secret-secret), disk-nya sebaiknya kita enkripsi saat diam.

Cluster

Bagian ini akan memberikan tautan-tautan untuk mengamankan beban-beban kerja di dalam Kubernetes. Ada dua area yang menjadi perhatian untuk mengamankan Kubernetes:

  • Mengamankan komponen-komponen yang dapat dikonfigurasi yang membentuk klaster
  • Mengamankan komponen-komponen yang dijalankan di dalam klaster

Komponen-komponen dari Cluster

Jika kamu ingin menjaga klastermu dari akses yang tidak disengaja atau yang bersifat serangan, dan mengadopsi praktik yang baik, baca dan ikutilah nasihat untuk mengamankan klastermu.

Komponen-komponen di dalam Cluster (aplikasimu)

Bergantung pada permukaan yang dapat diserang dari aplikasimu, kamu mungkin ingin berfokus pada aspek keamanan yang spesifik. Sebagai contoh, jika kamu menjalankan sebuah layanan (kita sebut Layanan A) yang kritikal di dalam rantai sumber daya lainnya dan sebuah beban kerja terpisah (kita sebut Layanan B) yang rentan terhadap serangan resource exhaustion, dengan tidak menyetel limit untuk sumber daya maka kamu juga menaruh risiko terhadap Layanan A. Berikut tabel tautan-tautan menuju hal-hal yang perlu diperhatikan untuk mengamankan beban-beban kerja yang berjalan di dalam Kubernetes.

Area yang Menjadi Perhatian untuk Keamanan Beban Kerja Rekomendasi
Otorisasi RBAC (Akses terhadap API Kubernetes) https://kubernetes.io/docs/reference/access-authn-authz/rbac/
Autentikasi https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/
Manajemen Secret Aplikasi (dan mengenkripsi mereka di etcd) https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
Pod Security Policy https://kubernetes.io/docs/concepts/policy/pod-security-policy/
Quality of Service (dan manajemen sumber daya klaster) https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
Network Policy https://kubernetes.io/docs/concepts/services-networking/network-policies/
TLS untuk Ingress Kubernetes https://kubernetes.io/docs/concepts/services-networking/ingress/#tls

Container

Untuk menjalankan perangkat lunak di dalam Kubernetes, perangkat lunak tersebut haruslah berada di dalam sebuah Container. Karenanya, ada beberapa pertimbangan keamanan yang harus diperhitungkan untuk mengambil manfaat dari fitur-fitur keamanan beban kerja Kubernetes. Keamanan Container berada di luar lingkup panduan ini, tetapi berikut disediakan sebuah tabel rekomendasi-rekomendasi umum dan tautan menuju eksplorasi lebih dalam pada topik ini.

Area yang Menjadi Perhatian untuk Container Rekomendasi
Pemindaian Kerentanan Container dan Dependensi Keamanan OS Sebagai bagian dari tahap membangun sebuah image atau dilakukan secara teratur, kamu sebaiknya memindai Container-container terhadap kerentanan yang telah diketahui dengan peralatan seperti CoreOS's Clair
Penandatanganan Image dan Penegakan Aturan Dua dari Proyek-proyek CNCF (TUF dan Notary) adalah alat-alat yang berguna untuk menandatangani image Container dan memelihara sistem kepercayaan untuk konten dari Container-container kamu. Jika kamu menggunakan Docker, ia dibangun di dalam Docker Engine sebagai Docker Content Trust. Pada bagian penegakan aturan, proyek Portieris dari IBM adalah sebuah alat yang berjalan sebagai sebuah Dynamic Admission Controller Kubernetes untuk memastikan bahwa image-image ditandatangani dengan tepat oleh Notary sebelum dimasukkan ke dalam Cluster.
Larang pengguna-pengguna dengan hak istimewa Saat membangun Container-container, rujuklah dokumentasimu untuk cara membuat pengguna-pengguna di dalam Container-container yang memiliki hak istimewa sistem operasi yang paling sedikit yang dibutuhkan untuk mencapai tujuan Container tersebut.

Code

Akhirnya pada lapisan kode aplikasi, hal ini adalah satu dari permukaan-permukaan serangan utama yang paling dapat kamu kontrol. Hal ini juga berada di luar lingkup Kubernetes, tetapi berikut beberapa rekomendasi:

Tabel Panduan Umum Keamanan Kode

Area yang Menjadi Perhatian untuk Kode Rekomendasi
Akses hanya melalui TLS Jika kode kamu perlu berkomunikasi via TCP, idealnya ia melakukan TLS handshake dengan klien sebelumnya. Dengan pengecualian pada sedikit kasus, kelakuan secara bawaan sebaiknya adalah mengenkripsi semuanya (data) pada saat transit (encryption at transit). Lebih jauh lagi, bahkan "di belakang dinding api" di dalam VPC kita sebaiknya kita melakukan enkripsi lalu lintas jaringan di antara layanan-layanan. Hal ini dapat dilakukan melalui sebuah proses yang dikenal dengan mutual TLS atau mTLS yang melakukan verifikasi dua sisi terhadap komunikasi antara layanan-layanan yang memiliki sertifikat digital. Ada banyak alat-alat yang dapat digunakan untuk mencapai hal ini, seperti Linkerd dan Istio.
Membatasi cakupan porta komunikasi Rekomendasi ini sepertinya cukup jelas, tetapi di mana pun dapat dilakukan sebaiknya kamu hanya membuka porta-porta pada layananmu yang benar-benar diperlukan untuk komunikasi sistem atau pengambilan metrik.
Keamanan Dependensi Pihak ke-3 Karena aplikasi-aplikasi kita cenderung memiliki dependensi-dependensi di luar kode kita sendiri, merupakan praktik yang baik untuk memastikan hasil pemindaian rutin dependensi-dependensi kode kita masih aman tanpa CVE yang masih ada terhadap mereka. Setiap bahasa pemrograman memiliki alat untuk melakukan pemindaian ini secara otomatis.
Analisis Statis Kode Kebanyakan bahasa pemrograman menyediakan cara agar potongan kode dapat dianalisis terhadap praktik-praktik penulisan kode yang berpotensi tidak aman. Kapan pun dapat dilakukan, kamu sebaiknya melakukan pemeriksaan menggunakan peralatan otomatis yang dapat memindai kode terhadap kesalahan keamanan yang umum terjadi. Beberapa dari peralatan tersebut dapat ditemukan di sini: https://www.owasp.org/index.php/Source_Code_Analysis_Tools
Serangan Pengamatan (probing) Dinamis Ada sedikit peralatan otomatis yang dapat dijalankan terhadap layanan/aplikasi kamu untuk mencoba beberapa serangan yang terkenal dan umumnya memengaruhi layanan-layanan. Serangan-serangan tersebut termasuk SQL injection, CSRF, dan XSS. Satu dari alat analisis dinamis yang terkenal adalah OWASP Zed Attack Proxy https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Otomasi yang Kokoh

Kebanyakan dari saran yang disebut di atas dapat diotomasi di dalam delivery pipeline kode kamu sebagai bagian dari rangkaian pemeriksaan keamanan. Untuk mempelajari lebih lanjut tentang pendekatan "Continuous Hacking" terhadap delivery perangkat lunak, artikel ini menyediakan lebih banyak detail.

Selanjutnya

2 - Panduan Pengamanan - Mekanisme Autentikasi

Informasi tentang opsi autentikasi di Kubernetes dan security properties -nya.

Memilih mekanisme autentikasi yang tepat adalah aspek penting dalam mengamankan kluster Anda. Kubernetes menyediakan beberapa mekanisme bawaan, masing-masing dengan kelebihan dan kekurangannya yang harus dipertimbangkan dengan hati-hati saat memilih mekanisme autentikasi terbaik untuk kluster Anda.

Secara umum, disarankan untuk mengaktifkan sesedikit mungkin mekanisme autentikasi untuk menyederhanakan manajemen pengguna dan mencegah kasus di mana pengguna tetap memiliki akses ke kluster yang tidak lagi diperlukan.

Penting untuk dicatat bahwa Kubernetes tidak memiliki basis data pengguna bawaan di dalam kluster. 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 kluster 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.

Autentikasi sertifikat klien X.509

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:

  • Sertifikat klien tidak dapat dicabut secara individual. Setelah disusupi, sertifikat dapat digunakan oleh penyerang hingga kedaluwarsa. Untuk mengurangi risiko ini, disarankan untuk mengonfigurasi masa berlaku yang pendek untuk kredensial autentikasi pengguna yang dibuat menggunakan sertifikat klien.
  • Jika sertifikat perlu dibatalkan, otoritas sertifikat harus diubah kuncinya, yang dapat memperkenalkan risiko ketersediaan ke kluster.
  • Tidak ada catatan permanen tentang sertifikat klien yang dibuat di kluster. Oleh karena itu, semua sertifikat yang diterbitkan harus dicatat jika Anda perlu melacaknya.
  • Kunci privat yang digunakan untuk autentikasi sertifikat klien tidak dapat dilindungi dengan kata sandi. Siapa pun yang dapat membaca file yang berisi kunci tersebut akan dapat menggunakannya.
  • Menggunakan autentikasi sertifikat klien memerlukan koneksi langsung dari klien ke API server tanpa titik terminasi TLS yang mengintervensi, yang dapat mempersulit arsitektur jaringan.
  • Data grup tertanam dalam nilai O dari sertifikat klien, yang berarti keanggotaan grup pengguna tidak dapat diubah selama masa berlaku sertifikat.

File token statis

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:

  • Kredensial disimpan dalam teks biasa di disk node control plane, yang dapat menjadi risiko keamanan.
  • Mengubah kredensial apa pun memerlukan restart proses API server agar berlaku, yang dapat memengaruhi ketersediaan.
  • Tidak ada mekanisme yang tersedia untuk memungkinkan pengguna memutar kredensial mereka. Untuk memutar kredensial, administrator kluster harus memodifikasi token di disk dan mendistribusikannya ke pengguna.
  • Tidak ada mekanisme penguncian yang tersedia untuk mencegah serangan brute-force.

Token bootstrap

Token bootstrap digunakan untuk menghubungkan node ke kluster dan tidak disarankan untuk autentikasi pengguna karena beberapa alasan:

  • Mereka memiliki keanggotaan grup yang dikodekan keras yang tidak cocok untuk penggunaan umum, sehingga tidak cocok untuk tujuan autentikasi.
  • Pembuatan token bootstrap secara manual dapat menghasilkan token yang lemah yang dapat ditebak oleh penyerang, yang dapat menjadi risiko keamanan.
  • Tidak ada mekanisme penguncian yang tersedia untuk mencegah serangan brute-force, sehingga memudahkan penyerang untuk menebak atau memecahkan token.

Token rahasia ServiceAccount

Rahasia akun layanan tersedia sebagai opsi untuk memungkinkan beban kerja yang berjalan di kluster 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:

  • Mereka tidak dapat diatur dengan masa berlaku dan akan tetap berlaku hingga akun layanan terkait dihapus.
  • Token autentikasi terlihat oleh pengguna kluster mana pun yang dapat membaca rahasia di namespace tempat mereka didefinisikan.
  • Akun layanan tidak dapat ditambahkan ke grup arbitrer, yang mempersulit manajemen RBAC di mana mereka digunakan.

Token API TokenRequest

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.

Autentikasi token OpenID Connect

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:

  • Perangkat lunak yang diinstal di kluster untuk mendukung autentikasi OIDC harus diisolasi dari beban kerja umum karena akan berjalan dengan hak istimewa tinggi.
  • Beberapa layanan Kubernetes yang dikelola memiliki batasan pada penyedia OIDC yang dapat digunakan.
  • Seperti halnya token TokenRequest, token OIDC harus memiliki masa berlaku yang pendek untuk mengurangi dampak token yang disusupi.

Autentikasi token Webhook

Autentikasi token Webhook adalah opsi lain untuk mengintegrasikan penyedia autentikasi eksternal ke Kubernetes. Mekanisme ini memungkinkan layanan autentikasi, baik yang berjalan di dalam kluster 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 kluster untuk mendukung akses ini harus diisolasi dari beban kerja umum, karena akan berjalan dengan hak istimewa tinggi.

Proxy autentikasi

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.

Selanjutnya