kubectl работает через VPN, но AKS перестаёт масштабироваться: почему

Вы добавляете публичный адрес офисного 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 перечисляет поддерживаемые параметры и требования платформы, которые должны входить в тот же список, — это та часть, которую большинство описаний заявок опускает.