kubectl VPN üzərindən işləyir, amma AKS miqyaslanmanı dayandırır: niyə

Ofis VPN-inin açıq ünvanını AKS API serverinin icazə siyahısına əlavə edirsiniz və kubectl işləyir. Bir həftə sonra node pool-un miqyaslanması uğursuz olur, CI işi klasterə çata bilmir və portal IP aralıqları barədə heç nə deməyən xəta göstərir. Siyahını heç kim dəyişməyib. Aktivləşdirdiyiniz nəzarət API serverin qarşısındakı açıq IP filtrdir və o, kimin zəng etdiyini bilmir, yalnız zəngin hansı ünvandan gəldiyini bilir. VPN klasterin ehtiyac duyduğu bir neçə ünvandan biridir və ilk sınan nadir hallarda o olur.

İcazə siyahısı şəxslə deyil, ünvanla uyğunlaşır

--api-server-authorized-ip-ranges CIDR bloklarını qəbul edir, istifadəçiləri və ya qrupları yox. Tərtibatçının sorğusu VPN serverindən Azure-a çıxdıqda, API serverdəki mənbə ünvanı VPN serverinin açıq çıxışıdır. Buna görə həmin VPN-dəki hər kəs bir girişi paylaşır və VPN-dən kənarda olan hər kəs autentifikasiyaya qədər rədd edilir.

Bu o deməkdir ki, giriş nəzərdə tutduğunuzdan daha çox insanı buraxır. VPN girişi olan podratçı, eyni konsentrator üzərindəki şəxsi noutbuk və ələ keçirilmiş hesab hamısı eyni ünvandan gəlir. Klaster avtorizasiyası dəyişməyib, ona görə rol əsaslı giriş nəzarəti hələ də zəng edənin nə edə biləcəyini müəyyən edir, lakin icazə siyahısı kimlik nəzarəti deyil və heç vaxt belə təsvir edilməməlidir.

İlk sınan adətən kubectl olmur

İcazə siyahısı API serverin açıq endpoint-inə aiddir, ona görə siyahıdakı ünvanlardan kənarda olan hər şey dərhal işləməyi dayandırır. Aşkar itkilər VPN marşrutu olmayan ikinci ofis, hostinq boru xəttindəki CI runner və qoşulmağı unudan noutbukdur. Bunları tanımaq asandır, çünki bir insan gözləyir.

Daha az aşkar hal Azure və ya öz alətlərinizin idarə etdiyi avtomatlaşdırmadır. Bəzi platforma tərəfindən başladılan əməliyyatlar API serverə VPN-iniz olmayan ünvanlardan çatır və onlardan biri siyahı sərtləşdirildikdən dərhal sonra uğursuz olmağa başlayanda vaxt uyğunluğu ipucu olur. İnteraktiv giriş işləyir deyə siyahının tam olduğunu düşünməyin; klasterin xarab olduğu qənaətinə gəlməzdən əvvəl funksiyanın regionunuz və abunələriniz üçün nə tələb etdiyini yoxlayın.

Uğursuzluq əlaməti kömək edir. Əgər sorğu heç vaxt autentifikasiyaya çatmırsa, bu filtdir. Əgər autentifikasiyadan keçib sonra icazə xətası alırsa, filtr öz işini görüb və problem icazə siyahısına heç toxunmayan rol əsaslı giriş nəzarətindədir.

Bütün siyahını bir əmrlə qurun

Yeniləmə parametri giriş əlavə etmək əvəzinə bütün siyahını əvəz edir, ona görə yalnız VPN ünvanını daşıyan əmr orada olan hər şeyi səssizcə atır. Əvvəlcə cari dəyəri oxuyun, saxlayın və birləşməni göndərin:

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üvənməzdən əvvəl VPN serveri üçün rezerv edilmiş açıq IP istifadə edin. Dinamik ünvan yenidən qoşulduqda dəyişir və hər dəyişiklik komandanı klasterdən səssizcə kənarda saxlayır, ta ki kimsə siyahını hələ icazə verilən şəbəkədən yeniləyənə qədər. Artıqlıq üçün iki VPN çıxış nöqtəniz varsa, hər ikisini göstərin, çünki filtrin üstünlük verilən yol anlayışı yoxdur.

Dəyişikliyi elə ardıcıllaşdırın ki, ilk icazə verilən cəhd eyni zamanda sınaq olsun. Yeni siyahını elan edin, tətbiq edin və dərhal VPN-dən qoşulun; bunu tərs qaydada etmək CIDR blokundakı yazı səhvini düzəltmək üçün API serverə heç kimin çata bilmədiyi bir pəncərə yaradır.

İcazə siyahısının heç vaxt əhatə etmədiyi şeylər

O, API serveri şəxsi etmir. Şəxsi klaster şəxsi endpoint və şəxsi DNS istifadə edir və icazə verilmiş aralıqlar siyahısı onu əvəz edən nəzarət deyil. O, həmçinin buraxılmış zəng edənin nə edə biləcəyini dəyişmir, ona görə sızmış admin kubeconfig istənilən icazəli ünvandan hələ də işləyir. Etimadnaməni təhlükəsizlik sərhədi, siyahını isə şəbəkə rahatlığı kimi qəbul edin.

Onun iş yükləri ilə heç bir əlaqəsi yoxdur. Siyahı aktiv olduqda Pods və Services işləməyə davam edir və VPN üzərindən tətbiqə çatmaq ayrı bir problemdir: yalnız klaster IP-si olan Service hələ də daxili yük balanslaşdırıcısı, ingress və ya port-forward tələb edir ki, noutbuk onu aça bilsin. Bu iki dizaynı qarışdırmaq tərtibatçıları məhdudlaşdırdığını iddia edən, əslində isə tətbiqlərlə bağlı heç nəyi məhdudlaşdırmayan dəyişiklik bileti yaradır.

Hər iki tərəfdən yoxlayın, sonra bir real əməliyyat icra edin

VPN-də təzə client ilə və ondan kənarda olan client ilə sınayın. Kənar cəhd ad həllində deyil, API serverdə rədd edilməlidir; əgər ad həll olunmursa, siz DNS-i sınaqdan keçirirsiniz və filtr barədə heç nə öyrənməmisiniz. Sonra interaktiv kubectl çağırışı olmayan bir əməliyyat icra edin, məsələn node pool miqyaslanması və ya yüksəltmə yoxlaması, və belə olacağını güman etmək əvəzinə onun tamamlandığını təsdiqləyin.

Əvvəlki siyahı dəyərini dəyişikliyin yanında qeyd edin və yazılmış əmrə güvənmək əvəzinə yeniləmədən sonra effektiv dəyəri yenidən oxuyun. AKS icazə verilmiş IP aralıqları sənədləşməsi dəstəklənən parametrləri və eyni siyahıya aid olan platforma tələblərini sadalayır, bu da əksər bilet təsvirlərinin buraxdığı hissədir.