Ofis VPN'inin genel adresini AKS API sunucusunun izin listesine eklersiniz ve kubectl çalışır. Bir hafta sonra bir node pool ölçeklemesi başarısız olur, bir CI işi kümeye ulaşamaz ve portal IP aralıklarından hiç söz etmeyen bir hata gösterir. İzin listesini kimse değiştirmedi. Etkinleştirdiğiniz kontrol API sunucusunun önündeki genel bir IP filtresidir ve kimin aradığını bilmez, yalnızca çağrının hangi adresten geldiğini bilir. VPN, kümenin ihtiyaç duyduğu birkaç adresten biridir ve ilk bozulanın o olması nadirdir.

İzin listesi bir adresle eşleşir, bir kişiyle değil

--api-server-authorized-ip-ranges CIDR bloklarını kabul eder, kullanıcıları veya grupları değil. Bir geliştiricinin isteği VPN sunucusundan Azure'a çıktığında, API sunucusundaki kaynak adres VPN sunucusunun genel çıkışıdır. Bu yüzden o VPN'deki herkes tek bir girdiyi paylaşır ve VPN dışındaki herkes kimlik doğrulama gerçekleşmeden önce reddedilir.

Bu aynı zamanda girdinin amaçladığınızdan daha fazla kişiyi içeri aldığı anlamına gelir. VPN erişimi olan bir yüklenici, aynı yoğunlaştırıcıdaki kişisel bir dizüstü bilgisayar ve ele geçirilmiş bir hesap, hepsi aynı adresten gelir. Küme yetkilendirmesi değişmedi, bu nedenle rol tabanlı erişim denetimi arayanın ne yapabileceğine hâlâ karar verir, ancak izin listesi bir kimlik denetimi değildir ve asla öyle tanımlanmamalıdır.

İlk bozulan genellikle kubectl değildir

İzin listesi API sunucusunun genel uç noktası için geçerlidir, bu yüzden listelediğiniz adreslerin dışındaki her şey anında çalışmayı bırakır. Bariz kayıplar VPN rotası olmayan ikinci ofis, barındırılan bir iş akışındaki CI çalıştırıcısı ve bağlanmayı unutan bir dizüstü bilgisayardır. Bunları tanımak kolaydır çünkü bekleyen bir insan vardır.

Daha az belirgin durum, Azure'un veya kendi araçlarınızın yönettiği otomasyondur. Platform tarafından başlatılan bazı işlemler API sunucusuna VPN'iniz olmayan adreslerden ulaşır ve bunlardan biri liste sıkılaştırıldıktan hemen sonra başarısız olmaya başlarsa, zamanlama ipucudur. Etkileşimli erişim çalışıyor diye listenin eksiksiz olduğunu varsaymayın; kümenin bozuk olduğu sonucuna varmadan önce özelliğin bölgeniz ve abonelikleriniz için ne gerektirdiğini kontrol edin.

Arıza imzası yardımcı olur. İstek hiçbir zaman kimlik doğrulamaya ulaşmıyorsa, filtre odur. Kimlik doğrulanıp ardından izin hatası alınıyorsa, filtre işini yapmıştır ve sorun izin listesinin hiç dokunmadığı rol tabanlı erişim denetimindedir.

Listenin tamamını tek komutta oluşturun

Güncelleme parametresi bir girdi eklemek yerine listenin tamamını değiştirir, bu nedenle yalnızca VPN adresini taşıyan bir komut orada bulunan diğer her şeyi sessizce düşürür. Önce mevcut değeri okuyun, saklayın ve birleşimi gönderin:

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

Buna güvenmeden önce VPN sunucusu için ayrılmış bir genel IP kullanın. Dinamik adres yeniden bağlanınca değişir ve her değişiklik, hâlâ izin verilen bir ağdan biri listeyi güncelleyene kadar ekibi sessizce kümenin dışında kilitler. Yedeklilik için iki VPN çıkış noktanız varsa ikisini de listeleyin, çünkü filtrenin tercih edilen yol diye bir kavramı yoktur.

Değişikliği, ilk izin verilen deneme aynı zamanda test olacak şekilde sıralayın. Yeni listeyi duyurun, uygulayın ve hemen VPN'den bağlanın; ters sırada yapmak, CIDR bloğundaki bir yazım hatasını düzeltmek için kimsenin API sunucusuna ulaşamadığı bir pencere bırakır.

İzin listesinin asla kapsamadığı şey

API sunucusunu özel yapmaz. Özel bir küme özel bir uç nokta ve özel DNS kullanır ve yetkili aralık listesi bunun yerini alan kontrol değildir. Kabul edilen arayanın ne yapabileceğini de değiştirmez, bu nedenle sızmış bir yönetici kubeconfig'i izin verilen herhangi bir adresten hâlâ çalışır. Kimlik bilgilerini güvenlik sınırı, listeyi ise ağ kolaylığı olarak görün.

İş yükleriyle hiçbir ilgisi yoktur. Liste etkinken Pods ve Services çalışmaya devam eder ve VPN üzerinden bir uygulamaya ulaşmak ayrı bir sorundur: yalnızca küme IP'sine sahip bir Service, bir dizüstü bilgisayarın açabilmesi için hâlâ dahili bir yük dengeleyiciye, bir ingress'e veya bir port-forward'a ihtiyaç duyar. Bu iki tasarımı karıştırmak, geliştiricileri kısıtladığını iddia eden ancak uygulamalar konusunda hiçbir şeyi kısıtlamayan bir değişiklik bileti üretir.

İki taraftan doğrulayın, ardından bir gerçek işlem çalıştırın

VPN'de yeni bir istemciyle ve dışarıdaki bir istemciyle test edin. Dışarıdan gelen deneme ad çözümlemesinde değil, API sunucusunda reddedilmelidir; ad çözümlenmiyorsa, DNS'i test ediyorsunuz ve filtre hakkında hiçbir şey öğrenmediniz. Ardından etkileşimli bir kubectl çağrısı olmayan bir işlem çalıştırın, örneğin bir node pool ölçeklemesi veya bir yükseltme kontrolü, ve olacağını varsaymak yerine tamamlandığını doğrulayın.

Önceki liste değerini değişikliğin yanında kaydedin ve yazılan komuta güvenmek yerine güncellemeden sonra etkin değeri yeniden okuyun. AKS'nin izin verilen IP aralıkları belgeleri desteklenen parametreleri ve aynı listeye ait platform gereksinimlerini sıralar ve çoğu bilet açıklamasının atladığı kısım budur.

İlgili makaleler