Pensiunnya ingress-nginx dan Katalog Bitnami: Dampak bagi Pengguna Kubernetes

Pensiunnya ingress-nginx pada Maret 2026 berarti controller Ingress yang menurut Kubernetes dipakai sekitar separuh lingkungan cloud native itu tidak lagi menerima rilis dan patch keamanan. Di saat yang sama, perubahan katalog Bitnami sejak Agustus 2025 membuat banyak Helm chart dan image yang dipakai tim DevOps tidak lagi mendapat pembaruan gratis. Keduanya perlu masuk rencana migrasi Anda.

Apa yang Terjadi dengan ingress-nginx

Kubernetes SIG Network dan Security Response Committee mengumumkan rencana pensiun ingress-nginx pada 11 November 2025, dengan alasan menjaga keselamatan dan keamanan ekosistem. Pemeliharaan best-effort berlanjut sampai Maret 2026; rilis controller terakhir terbit pada 19 Maret 2026, dan repositori kubernetes/ingress-nginx kini diarsipkan (read-only). Setelah itu tidak ada lagi rilis, perbaikan bug, maupun patch kerentanan. Pada Januari 2026, Steering Committee dan Security Response Committee Kubernetes menegaskan bahwa bertahan di ingress-nginx membuat Anda rentan diserang, mengutip riset internal Datadog bahwa sekitar 50% lingkungan cloud native memakainya, sementara proyek ini bertahun-tahun hanya dipelihara satu atau dua orang di waktu luang. Deployment yang ada tetap berjalan, sehingga tanpa pengecekan aktif Anda bisa tidak sadar sedang terdampak. Ingat bahwa yang dipensiunkan adalah controller ingress-nginx, bukan API Ingress itu sendiri: API Ingress tetap ada namun dibekukan fiturnya (feature-frozen).

Controller ini pernah menjadi sorotan lewat CVE-2025-1974 (Maret 2025, CVSS 3.1 9.8 menurut Kubernetes): pada kondisi tertentu, penyerang tanpa autentikasi yang punya akses ke jaringan pod dapat mengeksekusi kode dalam konteks controller dan membuka Secret yang dapat diaksesnya. Pada instalasi default, controller dapat mengakses semua Secret di seluruh cluster. Ingress controller juga berada di jalur semua trafik masuk, sehingga komponen yang tidak dipelihara di posisi itu adalah risiko yang nyata. Pembahasan konfigurasi yang salah yang sering menyertainya ada di Security Misconfiguration.

Opsi Migrasi dari ingress-nginx

SIG Network dan Security Response Committee menyarankan migrasi segera ke Gateway API atau controller Ingress lain. Sebuah tulisan di blog CNCF (9 Juli 2026, oleh Sunny Chan dari TCC Consulting) memaparkan dua jalur utama:

• Jalur A, pindah ke controller lain yang dipelihara (misalnya Contour). Resource Ingress tetap dipakai dan hanya ingress class yang diganti. Penulis menyebutnya solusi sementara bagi tim yang kekurangan waktu. Anotasi nginx.ingress.kubernetes.io/* harus diterjemahkan secara manual atau dibangun ulang dengan CRD controller baru.
• Jalur B, pindah ke Gateway API. Ini penerus Ingress yang didukung upstream. Usahanya lebih besar karena manifest routing ditulis ulang, tetapi memberi pemisahan peran dan routing lanjutan bawaan.

Langkah yang dianjurkan: audit anotasi nginx.ingress.kubernetes.io/* yang dipakai, gunakan alat ingress2gateway untuk membantu penerjemahan, jalankan controller lama dan baru secara paralel, lalu pindahkan beban kerja non-kritis lebih dulu. Perilaku anotasi sering berbeda halus antar controller, jadi uji tiap rute (redirect, rewrite, batas ukuran body, timeout, autentikasi) sebelum memindahkan trafik produksi.

Perubahan Katalog Bitnami: Image dan Chart yang Terpengaruh

Menurut catatan resmi Bitnami di GitHub, katalog publik docker.io/bitnami beralih ke subset komunitas yang terbatas pada 28 Agustus 2025, dengan penghapusan katalog lama yang diundur ke 29 September 2025 setelah beberapa brownout. Ringkasannya:

• Tier gratis hanya berisi sejumlah kecil image hardened di bitnamisecure, untuk pengembangan dan hanya tag latest.
• Image versi lama dipindahkan ke docker.io/bitnamilegacy yang tidak menerima pembaruan maupun dukungan dan hanya dimaksudkan untuk migrasi sementara.
• Bitnami Secure Images berbayar menawarkan image hardened, build SLSA Level 3, SBOM, cabang LTS, dan dukungan.
• Helm chart: chart OCI lama tetap di docker.io/bitnamicharts tetapi tidak diperbarui dan mungkin gagal dipasang tanpa mengganti image; kode sumber chart di GitHub tetap berlisensi Apache 2.0.

Mengganti repository image ke bitnamilegacy memang bisa menyelamatkan deployment untuk sementara, tetapi image di sana tidak mendapat patch, sehingga ini bukan solusi jangka panjang untuk produksi.

Daftar Cek Audit untuk Tim Kubernetes

1. Cari ingress-nginx dengan perintah yang disarankan Kubernetes (butuh hak admin cluster): kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx, lalu periksa juga IngressClass yang terpasang.
2. Daftar semua anotasi nginx.ingress.kubernetes.io pada resource Ingress.
3. Cari image dengan prefiks bitnami/ di manifest, values Helm, dan CI/CD, lalu catat tag yang dipakai.
4. Pin image berdasarkan digest, simpan di registri internal, dan pindai kerentanan secara rutin.
5. Terapkan prioritas patch berbasis risiko; lihat Patch Management Berbasis Risiko.
6. Tambahkan komponen ini ke SBOM dan kalender akhir masa dukungan (end-of-life).

Prinsip yang sama berlaku untuk keamanan infrastruktur cloud secara umum; lihat Masalah Keamanan Data pada Cloud Computing.

Relevansi bagi Pengguna Kubernetes di Indonesia

Jika tim Anda memakai kombinasi ingress-nginx dan chart Bitnami, misalnya karena mengikuti tutorial atau warisan proyek awal, kombinasi ini kini sebaiknya diperlakukan sebagai utang teknis yang punya tenggat. Mulailah dari cluster yang menerima trafik internet dan menyimpan data pribadi.

Gateway API: Apa yang Berbeda dari Ingress

Gateway API memisahkan peran yang pada Ingress bercampur dalam satu resource. Operator platform mengelola GatewayClass dan Gateway (pintu masuk dan listener), sedangkan tim aplikasi mengelola rute seperti HTTPRoute untuk aplikasi mereka sendiri. Pemisahan ini mendukung prinsip least privilege karena tim aplikasi tidak perlu menyentuh konfigurasi TLS tingkat cluster. Fitur yang dahulu bergantung pada anotasi kustom, seperti pencocokan header, pembagian trafik, dan routing lintas namespace, kini bagian dari spesifikasi resmi sehingga lebih mudah ditinjau dan dipindahkan antar implementasi. Namun tidak setiap anotasi ingress-nginx punya padanan langsung, jadi terjemahan otomatis tetap perlu ditinjau manual.

Rencana Migrasi Bertahap ingress-nginx

1. Tetapkan tenggat internal. Controller yang sudah pensiun tidak akan menerima patch baru, jadi tentukan tanggal target selesai.
2. Mulai dari lingkungan non-produksi dan satu layanan percontohan dengan konfigurasi sederhana.
3. Jalankan paralel. Pasang controller baru dengan IngressClass atau Gateway terpisah dan uji dengan hostname uji sebelum mengubah DNS.
4. Pindahkan trafik bertahap lewat pembobotan DNS atau load balancer, dengan rencana rollback yang jelas.
5. Cabut controller lama hanya setelah seluruh rute terverifikasi, lalu hapus resource dan secret yang tidak dipakai.

Catat keputusan dan hasil pengujian sebagai bahan audit. Dokumentasi yang rapi mempermudah tim berikutnya ketika controller pengganti suatu hari juga mencapai akhir masa dukungan.

Baca juga: Penangkapan Pengguna Alias Bjorka: Fakta Kasus dan Pelajarannya.

Pertanyaan yang Sering Diajukan

Apakah API Ingress ikut dihapus?

Tidak. API Ingress tetap ada tetapi fiturnya dibekukan; yang dipensiunkan adalah controller ingress-nginx.

Apakah chart Bitnami langsung berhenti bekerja?

Tidak otomatis, tetapi chart lama tidak lagi diperbarui dan mungkin gagal dipasang tanpa mengganti repository image.

Kapan sebaiknya mulai migrasi?

Sekarang. Audit dulu, lalu jalankan controller baru secara paralel dan pindahkan trafik bertahap.

Kesimpulan

Pensiunnya ingress-nginx dan perubahan katalog Bitnami adalah pengingat bahwa komponen gratis juga punya masa berlaku. Audit, pilih jalur migrasi, dan pin artefak Anda. Jika Anda ingin menilai keamanan cluster Kubernetes dan pipeline Anda secara independen, hubungi tim Linuxhackingid melalui halaman layanan.