Mengapa kubectl berfungsi melalui VPN tetapi AKS berhenti melakukan penskalaan

Anda menambah alamat awam VPN pejabat ke senarai dibenarkan pelayan AKS API, dan kubectl berfungsi. Seminggu kemudian penskalaan node pool gagal, tugas CI tidak dapat mencapai kluster, dan portal menunjukkan ralat yang tidak menyebut apa-apa tentang julat IP. Tiada siapa mengubah senarai dibenarkan. Kawalan yang anda aktifkan ialah penapis IP awam di hadapan pelayan API, dan ia tidak tahu siapa yang memanggil, hanya dari alamat mana panggilan itu datang. VPN ialah satu alamat antara beberapa yang diperlukan kluster, dan jarang alamat itulah yang rosak dahulu.

Senarai dibenarkan memadankan alamat, bukan orang

--api-server-authorized-ip-ranges menerima blok CIDR, bukan pengguna atau kumpulan. Apabila permintaan pembangun meninggalkan pelayan VPN menuju Azure, alamat sumber di pelayan API ialah egress awam pelayan VPN. Oleh itu setiap orang pada VPN itu berkongsi satu entri, dan sesiapa di luar VPN ditolak sebelum pengesahan berlaku.

Ini juga bermakna entri itu membenarkan lebih ramai orang daripada yang anda maksudkan. Kontraktor dengan akses VPN, komputer riba peribadi pada konsentrator yang sama, dan akaun yang diceroboh semuanya datang dari alamat yang sama. Kebenaran kluster tidak berubah, jadi kawalan akses berasaskan peranan masih menentukan apa yang boleh dilakukan pemanggil, tetapi senarai dibenarkan bukan kawalan identiti dan tidak sepatutnya pernah digambarkan sedemikian.

Yang rosak dahulu biasanya bukan kubectl

Senarai dibenarkan terpakai pada titik akhir awam pelayan API, jadi apa-apa di luar alamat yang anda senaraikan berhenti berfungsi serta-merta. Mangsa yang jelas ialah pejabat kedua tanpa laluan VPN, pelari CI dalam saluran paip yang dihoskan, dan komputer riba yang terlupa menyambung. Ini mudah dikenali kerana ada manusia yang menunggu.

Kes yang kurang jelas ialah automasi yang digerakkan oleh Azure atau alat anda sendiri. Sesetengah operasi yang dimulakan platform mencapai pelayan API dari alamat yang bukan VPN anda, dan apabila salah satunya mula gagal sejurus selepas senarai diketatkan, masa itulah petunjuknya. Jangan anggap senarai itu lengkap kerana akses interaktif berfungsi; semak apa yang diperlukan ciri itu untuk wilayah dan langganan anda sebelum membuat kesimpulan kluster itu rosak.

Tandatangan kegagalan membantu. Jika permintaan tidak pernah sampai ke pengesahan, itu penapisnya. Jika ia disahkan dan kemudian mendapat ralat kebenaran, penapis telah menjalankan tugasnya dan masalahnya ialah kawalan akses berasaskan peranan, yang tidak pernah disentuh senarai dibenarkan.

Bina seluruh senarai dalam satu arahan

Parameter kemas kini menggantikan seluruh senarai dan bukannya menambah entri, jadi arahan yang hanya membawa alamat VPN secara senyap menggugurkan segala-galanya yang ada di sana. Baca nilai semasa dahulu, simpan, dan hantar gabungan itu:

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 awam yang ditempah untuk pelayan VPN sebelum anda bergantung pada ini. Alamat dinamik berubah semasa menyambung semula, dan setiap perubahan mengunci pasukan di luar kluster secara senyap sehingga seseorang mengemas kini senarai dari rangkaian yang masih dibenarkan. Jika anda mempunyai dua titik egress VPN untuk redundansi, senaraikan kedua-duanya, kerana penapis tiada konsep laluan pilihan.

Susun perubahan supaya percubaan pertama yang dibenarkan juga menjadi ujian. Umumkan senarai baharu, gunakan, dan sambung dari VPN serta-merta; melakukannya dalam susunan terbalik meninggalkan tetingkap di mana tiada siapa boleh mencapai pelayan API untuk membetulkan salah taip dalam blok CIDR.

Apa yang tidak pernah diliputi senarai dibenarkan

Ia tidak menjadikan pelayan API peribadi. Kluster peribadi menggunakan titik akhir peribadi dan DNS peribadi, dan senarai julat dibenarkan bukan kawalan yang menggantikannya. Ia juga tidak mengubah apa yang boleh dilakukan pemanggil yang dibenarkan, jadi kubeconfig admin yang bocor masih berfungsi dari mana-mana alamat yang dibenarkan. Anggap kelayakan sebagai sempadan keselamatan dan senarai sebagai kemudahan rangkaian.

Ia tiada kaitan dengan beban kerja. Pods dan Services terus berjalan dengan senarai diaktifkan, dan mencapai aplikasi melalui VPN ialah masalah berasingan: Service yang hanya mempunyai IP kluster masih memerlukan pengimbang beban dalaman, ingress atau port-forward sebelum komputer riba boleh membukanya. Mencampur kedua-dua reka bentuk itu menghasilkan tiket perubahan yang mendakwa mengehadkan pembangun dan sebenarnya tidak mengehadkan apa-apa pada aplikasi.

Sahkan dari kedua-dua belah, kemudian jalankan satu operasi sebenar

Uji dengan klien baharu pada VPN dan dengan klien di luarnya. Percubaan dari luar sepatutnya ditolak di pelayan API, bukan pada penyelesaian nama; jika nama tidak dapat diselesaikan, anda sedang menguji DNS dan tidak mempelajari apa-apa tentang penapis. Kemudian jalankan operasi yang bukan panggilan kubectl interaktif, seperti penskalaan node pool atau pemeriksaan peningkatan, dan sahkan ia selesai dan bukannya menganggap ia akan selesai.

Catat nilai senarai sebelumnya di sebelah perubahan, dan baca semula nilai berkesan selepas kemas kini dan bukannya mempercayai arahan yang ditaip. dokumentasi AKS tentang julat IP dibenarkan menyenaraikan parameter yang disokong dan keperluan platform yang tergolong dalam senarai yang sama, dan itulah bahagian yang paling kerap ditinggalkan oleh keterangan tiket.