Mengapa kubectl bekerja lewat VPN tetapi AKS berhenti melakukan penskalaan

Anda menambahkan alamat publik VPN kantor ke daftar izin server AKS API, dan kubectl bekerja. Seminggu kemudian penskalaan node pool gagal, tugas CI tidak dapat menjangkau klaster, dan portal menampilkan kesalahan yang tidak menyebut apa pun tentang rentang IP. Tidak ada yang mengubah daftar izin. Kontrol yang Anda aktifkan adalah filter IP publik di depan server API, dan ia tidak tahu siapa yang memanggil, hanya dari alamat mana panggilan itu datang. VPN adalah satu alamat di antara beberapa yang dibutuhkan klaster, dan jarang alamat itulah yang rusak lebih dulu.

Daftar izin mencocokkan alamat, bukan orang

--api-server-authorized-ip-ranges menerima blok CIDR, bukan pengguna atau grup. Ketika permintaan pengembang meninggalkan server VPN menuju Azure, alamat sumber di server API adalah egress publik server VPN. Karena itu setiap orang di VPN tersebut berbagi satu entri, dan siapa pun di luar VPN ditolak bahkan sebelum autentikasi terjadi.

Itu juga berarti entri tersebut mengizinkan lebih banyak orang daripada yang Anda maksudkan. Kontraktor dengan akses VPN, laptop pribadi di konsentrator yang sama, dan akun yang disusupi semuanya datang dari alamat yang sama. Otorisasi klaster tidak berubah, jadi kontrol akses berbasis peran tetap menentukan apa yang boleh dilakukan pemanggil, tetapi daftar izin bukan kontrol identitas dan tidak boleh pernah digambarkan sebagai itu.

Yang rusak lebih dulu biasanya bukan kubectl

Daftar izin berlaku untuk endpoint publik server API, jadi apa pun di luar alamat yang Anda daftarkan langsung berhenti bekerja. Korban yang jelas adalah kantor kedua tanpa rute VPN, runner CI di pipeline terkelola, dan laptop yang lupa terhubung. Itu mudah dikenali karena ada manusia yang menunggu.

Kasus yang kurang jelas adalah otomatisasi yang dijalankan Azure atau perkakas Anda sendiri. Beberapa operasi yang dimulai platform menjangkau server API dari alamat yang bukan VPN Anda, dan ketika salah satunya mulai gagal tepat setelah daftar diperketat, waktunya adalah petunjuk. Jangan berasumsi daftar sudah lengkap karena akses interaktif bekerja; periksa apa yang dibutuhkan fitur tersebut untuk wilayah dan langganan Anda sebelum menyimpulkan klaster rusak.

Tanda kegagalan membantu. Jika permintaan tidak pernah mencapai autentikasi, itu filternya. Jika berhasil diautentikasi lalu mendapat kesalahan izin, filter sudah melakukan tugasnya dan masalahnya ada pada kontrol akses berbasis peran, yang tidak pernah disentuh daftar izin.

Bangun seluruh daftar dalam satu perintah

Parameter pembaruan mengganti seluruh daftar alih-alih menambah entri, jadi perintah yang hanya membawa alamat VPN diam-diam membuang semua yang lain yang ada di sana. Baca nilai saat ini dulu, simpan, dan kirim gabungannya:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

Gunakan IP publik yang dicadangkan untuk server VPN sebelum Anda bergantung pada ini. Alamat dinamis berubah saat menyambung ulang, dan setiap perubahan diam-diam mengunci tim di luar klaster sampai seseorang memperbarui daftar dari jaringan yang masih diizinkan. Jika Anda memiliki dua titik egress VPN untuk redundansi, daftarkan keduanya, karena filter tidak mengenal konsep jalur pilihan.

Urutkan perubahan sehingga percobaan pertama yang diizinkan juga menjadi uji coba. Umumkan daftar baru, terapkan, dan segera hubungkan dari VPN; melakukannya dalam urutan sebaliknya meninggalkan jendela di mana tidak ada yang bisa menjangkau server API untuk memperbaiki salah ketik di blok CIDR.

Apa yang tidak pernah dicakup daftar izin

Itu tidak membuat server API menjadi privat. Klaster privat menggunakan endpoint privat dan DNS privat, dan daftar rentang yang diizinkan bukan kontrol yang menggantikannya. Itu juga tidak mengubah apa yang boleh dilakukan pemanggil yang diizinkan, jadi kubeconfig admin yang bocor masih berfungsi dari alamat mana pun yang diizinkan. Perlakukan kredensial sebagai batas keamanan dan daftar sebagai kemudahan jaringan.

Itu tidak ada hubungannya dengan beban kerja. Pods dan Services tetap berjalan dengan daftar diaktifkan, dan menjangkau aplikasi lewat VPN adalah masalah terpisah: Service yang hanya memiliki IP klaster tetap membutuhkan penyeimbang beban internal, ingress, atau port-forward sebelum laptop dapat membukanya. Mencampur kedua desain itu menghasilkan tiket perubahan yang mengklaim membatasi pengembang dan sebenarnya tidak membatasi apa pun pada aplikasi.

Verifikasi dari kedua sisi, lalu jalankan satu operasi nyata

Uji dengan klien baru di VPN dan dengan klien di luarnya. Upaya dari luar seharusnya ditolak di server API, bukan pada resolusi nama; jika nama tidak terurai, Anda sedang menguji DNS dan belum belajar apa pun tentang filter. Lalu jalankan operasi yang bukan panggilan kubectl interaktif, seperti penskalaan node pool atau pemeriksaan peningkatan, dan pastikan operasi itu selesai alih-alih menganggapnya akan selesai.

Catat nilai daftar sebelumnya di samping perubahan, dan baca ulang nilai efektif setelah pembaruan alih-alih memercayai perintah yang diketik. dokumentasi AKS tentang rentang IP yang diizinkan mencantumkan parameter yang didukung dan persyaratan platform yang termasuk dalam daftar yang sama, dan itulah bagian yang paling sering dihilangkan oleh deskripsi tiket.