kubectl працює через VPN, але AKS перестає масштабуватися: чому

Авторизовані діапазони IP бачать публічний вихід VPN-сервера, а не розробника. Додайте діапазони платформи, інакше автоматизація та масштабування зламаються після зміни.

Ви додаєте публічну адресу офісного VPN до списку дозволених сервера API AKS, і kubectl працює. Через тиждень не вдається масштабувати пул вузлів, завдання CI не може дістатися до кластера, а портал показує помилку, у якій нічого не сказано про діапазони IP. Ніхто не змінював список дозволених. Увімкнений вами контроль — це фільтр публічних IP перед сервером API, і він не знає, хто викликає, лише з якої адреси надійшов виклик. VPN — одна з кількох адрес, потрібних кластеру, і рідко саме вона ламається першою.

Список дозволених зіставляє адресу, а не людину

--api-server-authorized-ip-ranges приймає блоки CIDR, а не користувачів чи групи. Коли запит розробника залишає VPN-сервер і прямує до Azure, вихідна адреса на сервері API — це публічний вихід VPN-сервера. Тому всі люди в цьому VPN поділяють один запис, а будь-кого поза VPN відхиляють ще до початку автентифікації.

Це також означає, що запис пропускає більше людей, ніж ви, можливо, розраховували. Підрядник із доступом до VPN, особистий ноутбук на тому самому концентраторі та скомпрометований обліковий запис приходять з однієї адреси. Авторизація кластера не змінюється, тому керування доступом на основі ролей і далі вирішує, що може робити викликач, але список дозволених не є контролем особистості й ніколи не повинен описуватися як такий.

Першим зазвичай ламається не kubectl

Список дозволених застосовується до публічної кінцевої точки сервера API, тому все за межами перелічених адрес одразу перестає працювати. Очевидні жертви — другий офіс без VPN-маршруту, виконавець CI у розміщеному конвеєрі та ноутбук, який забув підключитися. Їх легко розпізнати, бо чекає людина.

Менш очевидний випадок — автоматизація, якою керує Azure або ваші власні інструменти. Деякі операції, ініційовані платформою, досягають сервера API з адрес, які не є вашим VPN, і коли одна з них починає збоїти одразу після посилення списку, час — це підказка. Не вважайте список повним лише тому, що інтерактивний доступ працює; перевірте, що функція вимагає для вашого регіону та підписок, перш ніж оголосити кластер зламаним.

Підпис збою допомагає. Якщо запит так і не доходить до автентифікації, виннен фільтр. Якщо він автентифікується і потім отримує помилку дозволу, фільтр зробив свою справу, а проблема — у керуванні доступом на основі ролей, якого список дозволених ніколи не торкається.

Зберіть увесь список однією командою

Параметр оновлення замінює весь список, а не додає запис, тому команда, яка несе лише адресу VPN, мовчки відкидає все інше, що там було. Спершу прочитайте поточне значення, збережіть його та надішліть об’єднання:

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

Використовуйте зарезервований публічний IP для VPN-сервера, перш ніж покладатися на це. Динамічна адреса змінюється під час перепідключення, і кожна зміна тихо замикає команду поза кластером, доки хтось не оновить список із ще дозволеної мережі. Якщо у вас є дві точки виходу VPN для резервування, вкажіть обидві, бо фільтр не має поняття бажаного шляху.

Шикуйте зміну так, щоб перша дозволена спроба була й перевіркою. Оголосіть новий список, застосуйте його й одразу підключіться через VPN; у зворотному порядку залишається вікно, коли ніхто не може дістатися до сервера API, щоб виправити друкарську помилку в блоці CIDR.

Чого список дозволених так і не покрив

Він не робить сервер API приватним. Приватний кластер використовує приватну кінцеву точку й приватний DNS, і список авторизованих діапазонів не є тим контролем, який це замінює. Він також не змінює того, що може робити допущений викликач, тому витік адміністративного kubeconfig усе ще працює з будь-якої дозволеної адреси. Вважайте облікові дані межею безпеки, а список — мережевою зручністю.

Він не має нічого спільного з робочими навантаженнями. Поди й сервіси продовжують працювати з увімкненим списком, і дістатися до застосунку через VPN — окрема задача: сервісу, який має лише IP кластера, усе одно потрібен внутрішній балансувальник навантаження, ingress або port-forward, перш ніж ноутбук зможе його відкрити. Змішування цих двох проєктів породжує заявку на зміну, яка обіцяє обмежити розробників і насправді нічого не обмежує в застосунках.

Перевірте з обох боків, потім виконайте одну реальну операцію

Перевірте з новим клієнтом у VPN і з клієнтом поза нею. Спроба ззовні має бути відхилена на сервері API, а не під час розв’язання імен; якщо ім’я не розв’язується, ви перевіряєте DNS і не дізналися нічого про фільтр. Потім виконайте операцію, яка не є інтерактивним викликом kubectl, наприклад масштабування пулу вузлів або перевірку оновлення, і підтвердьте, що вона завершується, замість того щоб припускати це.

Запишіть попереднє значення списку поруч зі зміною та перечитайте чинне значення після оновлення, замість того щоб довіряти введеній команді. Документація про авторизовані діапазони IP у AKS перелічує підтримувані параметри та вимоги платформи, які мають входити до того самого списку, — це та частина, яку більшість описів заявок пропускає.

Схожі статті