Краткий ответ: как включить mTLS без разрыва трафика
mTLS в service mesh включают поэтапным ужесточением политики: сначала PERMISSIVE, затем STRICT на ограниченной области, после чего расширяют действие. Глобальный STRICT на всем mesh сразу, без проверки sidecar, внешних клиентов и фоновых задач, приводит к массовым 503 и connection reset.
Безопасный маршрут выглядит так: инвентаризация трафика, проверка control plane и sidecar, включение PERMISSIVE в тестовом namespace, анализ ошибок и метрик, канареечный STRICT для одного workload, расширение strict на связанные сервисы, контроль сертификатов и готовый rollback. Базовую настройку Istio и проверку sidecar перед rollout можно взять из практического руководства по внедрению Istio.
До перехода в strict убедитесь, что у обеих сторон трафика есть sidecar, что сертификаты выпускаются, а plaintext-клиенты выявлены. STRICT блокирует клиентов без mesh-прокси и внешние интеграции с несовместимыми настройками.
Рабочая схема миграции: аудит → permissive → canary strict → strict
Порядок действий зафиксируйте как контрольные точки. Каждый следующий шаг выполняйте только после проверки доступности, ошибок, latency и факта установления TLS-соединений.
- Аудит трафика и зависимостей. Собираете вызывающие сервисы, порты, протоколы, внешние адреса, cronjob и health checks.
- Проверка sidecar и control plane. У каждой стороны соединения должен работать proxy.
- PERMISSIVE в тестовом namespace или для небольшой группы workload. Наблюдаете смешанный трафик.
- Канареечный STRICT для одного сервиса. Проверяете доступность, ошибки и handshake.
- Расширение strict на связанные сервисы и namespace с повторной проверкой после каждого шага.
- Mesh-wide STRICT, когда все внутренние соединения подтвердили совместимость.
Когда нельзя включать strict на всем mesh сразу
Глобальное изменение политики блокирует легитимный трафик в таких сценариях:
- Внешние клиенты без sidecar обращаются к внутренним сервисам напрямую.
- Сервисы без sidecar-инъекции: legacy-приложения, временные поды, init-контейнеры.
- Jobs и cron-задачи, которые не успевают завершиться до включения strict.
- Нестандартные порты и протоколы, не распознанные mesh.
- Прямой доступ к pod IP в обход proxy.
- Multi-cluster и federation без согласованной trust domain.
- Временно отключенная инъекция proxy из-за ошибки admission webhook.
Что такое mTLS в service mesh и зачем он нужен Kubernetes-кластеру
Обычный TLS подтверждает сервер клиенту. mTLS добавляет проверку клиента сервером. В service mesh шифрование и проверка идентичности выносятся в sidecar-proxy, поэтому приложения обычно не требуют переписывания. Это ключевой сценарий для защиты east-west-трафика внутри кластера, где классического периметра недостаточно.
Подробнее архитектуру и управление трафиком в mesh можно изучить в руководстве по архитектуре Service Mesh.
TLS и mTLS: какая сторона подтверждает свою идентичность
Сравните по трем признакам: кто предъявляет сертификат, что проверяет принимающая сторона, какие атаки предотвращаются.
- TLS: сертификат предъявляет сервер, клиент проверяет сервер.
- mTLS: сертификаты предъявляют обе стороны, сервер дополнительно проверяет клиента.
- Предотвращает подмену сервера и клиента, перехват plaintext-трафика, повторное использование сессии и подключение чужого workload.
mTLS не заменяет авторизацию на уровне приложения. Он подтверждает идентичность workload, но не определяет, какие действия разрешены.
Как проходит запрос через sidecar-proxy
Приложение отправляет запрос локальному proxy. Локальный proxy устанавливает соединение с proxy удаленного сервиса, договаривается о TLS, проверяет сертификаты и передает приложению уже установленное соединение согласно политике mesh. Control plane выпускает сертификаты и доставляет конфигурацию.
Такой путь означает: настройки применяются к workload, а не только к приложению. Если sidecar отсутствует у клиента или сервера, mTLS не установится или соединение будет отклонено в strict.
mTLS как часть zero trust и микросегментации
Zero trust требует проверять не только IP и сетевой узел, но и идентичность конкретного workload. Микросегментация в облачной среде распространяется на отдельные workload и проверяет компоненты приложений и их поведение. mTLS закрывает канал и подтверждает стороны, а политики доступа определяют, кому разрешен конкретный запрос.
Связка работает через три элемента: идентичность сервиса, политику доступа и мониторинг поведения трафика. mTLS дает измеримый признак идентичности, на основе которого строятся AuthorizationPolicy.
Что mTLS не решает автоматически
После включения mTLS кластер не становится защищенным полностью. Остаются зоны, которые нужно закрывать отдельно:
- Авторизация запросов между сервисами.
- Контроль доступа к Kubernetes API и секретам приложения.
- Безопасность входящего и исходящего трафика за пределами mesh.
- Уязвимости самого приложения и некорректная обработка данных.
Дополнительно нужны NetworkPolicy, AuthorizationPolicy, контроль внешних точек входа и секретов. mTLS защищает только канал между участниками mesh.
Предварительная проверка совместимости сервисов перед переходом в strict
Preflight-чеклист снижает риск сбоя до изменения политик. Сначала собираете карту east-west-трафика и границы mesh, затем проверяете sidecar-инъекцию, типы протоколов, внешние зависимости, фоновые задачи и текущие ошибки. Для тестового кластера можно развернуть Kubernetes в облаке, например Timeweb Cloud, чтобы проверить миграцию без влияния на production.
Составить карту входящих и исходящих зависимостей
Для каждого workload зафиксируйте вызывающие сервисы, порты, протоколы, namespace, внешние адреса, jobs, health checks и административные подключения. Отдельно отметьте прямые обращения к pod IP и обход proxy. Такая карта покажет, какой клиент может быть заблокирован при strict.
Проверить наличие и состояние sidecar у обеих сторон
Главный класс несовместимости: один сервис ожидает mTLS, а его клиент или сервер не имеет прокси. Проверьте, что proxy внедрен, запущен и подключен к control plane. Сопоставьте список workload с фактическим потоком запросов, включая новые pod после rollout и временные задачи.
Отделить mesh-трафик от внешнего и legacy-трафика
Выделите ingress, egress, базы данных, очереди, сторонние API, сервисы в другом кластере и приложения без поддержки mesh. Для каждого направления определите: добавить ли proxy, оставить ли отдельное исключение или вынести миграцию в самостоятельный этап.
Проверить протоколы, порты и особенности приложений
Проверьте HTTP, HTTP/2, gRPC, TCP и нестандартные протоколы. Уточните, какие порты распознаются mesh, нет ли TLS внутри приложения, нестандартных health checks, long-lived connections и требований к исходному IP.
Определить метрики успеха и окно наблюдения
Зафиксируйте базовые значения доступности, latency, RPS, кодов 4xx/5xx, reset-соединений, TLS handshake errors и состояния proxy. Задайте период наблюдения, включающий обычную нагрузку, rollout и фоновые процессы. Это заменит субъективное «кажется, работает» измеримыми критериями.
Как включить mTLS в Istio: подготовка control plane и области действия политик
Порядок применения политик важнее самого факта добавления конфигурации. Настраивайте от общего к частному: состояние Istiod и CA, затем mesh-wide policy, namespace policy и workload policy. Точные поля и команды зависят от версии Istio, поэтому перед применением проверяйте синтаксис в используемом релизе.
Проверить Istiod, CA и выпуск сертификатов для workload
Проверьте состояние control plane, доверенную цепочку, выпуск сертификатов, сроки действия и синхронизацию конфигурации. Зафиксируйте, какая система CA используется и как выполняется ротация. Если proxy не может получить или проверить удостоверение, strict вызовет ошибки доверия.
Понять область действия PeerAuthentication
PeerAuthentication может применяться на уровне mesh-wide, namespace или workload. Проверяйте selector, namespace и приоритет более специфичной политики. Более узкая политика перекрывает общую. Конфликтующие объекты и неявное наследование создают риск, что strict включится не там.
Пример политики namespace-уровня в режиме PERMISSIVE:
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: payments
spec:
mtls:
mode: PERMISSIVEДля strict замените mode на STRICT. Область действия определяется namespace объекта и selector внутри политики.
Почему одной PeerAuthentication недостаточно для полного сценария
PeerAuthentication определяет, какие соединения принимаются. DestinationRule помогает управлять режимом исходящего взаимодействия. Это разделение критично: сервер может принимать mTLS, но клиент по-прежнему попытается отправить plaintext. Точная модель зависит от версии Istio, поэтому всегда проверяйте документацию релиза и фактическое поведение proxy.
Подготовить отдельные политики для исключений и переходных зон
Сохраните доступность legacy- и внешних интеграций через локальные исключения: минимальный scope, указанный владелец, срок действия и обязательное документирование. Постоянный permissive не должен заменять исправление несовместимости.
Пошаговое включение mTLS без разрыва трафика: от permissive к strict
Миграция строится как последовательность контролируемых изменений. На каждом этапе проверяйте предварительное условие, действие, что наблюдать и критерий перехода дальше. Это центральный практический блок статьи.
Этап 1. Зафиксировать исходное состояние и подготовить откат
Сохраните текущие манифесты и версии конфигурации, опишите затронутые workload, назначьте ответственного, подготовьте команды или манифесты возврата и проверьте доступ к наблюдаемости. Rollback должен быть подготовлен до изменения, а не в момент аварии.
Этап 2. Включить permissive в тестовой области
Начните с отдельного namespace или небольшой группы workload. PERMISSIVE принимает и mTLS, и plaintext. Убедитесь, что установление mTLS возможно, а существующие соединения сохраняют доступность. Зафиксируйте состояние proxy и ошибки handshake.
Этап 3. Наблюдать за смешанным трафиком и устранять несовместимости
PERMISSIVE используется как окно диагностики, а не как финальный режим безопасности. По метрикам и логам определите клиентов без proxy, ошибочные порты, неподдерживаемые протоколы, внешние вызовы и сервисы, которые обходят mesh. Исправьте конфигурацию или оформите минимальные временные исключения.
Этап 4. Перевести один workload или пару зависимых сервисов в strict
Выберите сервис с полной картой зависимостей и контролируемой нагрузкой. Переведите его в strict, проверьте запросы в обе стороны, health checks, gRPC или HTTP/2, фоновые задачи и поведение при rollout. Канареечный метод управления трафиком помогает ограничить радиус влияния.
Этап 5. Расширить strict на связанные сервисы и namespace
Расширяйте область действия группами, связанными графом зависимостей. После каждого шага проверяйте ошибки, latency, reset-соединения, доступность внешних интеграций и состояние сертификатов. Не переводите сразу весь namespace, если не все зависимости подтверждены.
Этап 6. Включить strict для mesh-wide области
Перед глобальным изменением повторно проверьте исключения, новые workload, системные namespace, ingress/egress и аварийный доступ. Зафиксируйте итоговую конфигурацию и условия, при которых выполняется rollback. Mesh-wide strict завершает миграцию только при нуле необъясненных сбоев.
Как проверить, что mTLS действительно работает
Проверка делится на четыре уровня: конфигурация, состояние proxy, наблюдаемость и сетевой handshake. Результат должен показывать факт шифрования и аутентификации, а не только наличие политики в репозитории.
Проверить примененную конфигурацию, а не только манифест
Сверьте ожидаемый scope политики с фактической конфигурацией proxy. Проверьте namespace, selector, revision Istio и время последнего обновления конфигурации. Манифест в git может быть перекрыт более специфичным объектом.
Проверить идентичность и сертификат workload
Проверьте наличие сертификата, срок действия, цепочку доверия, SAN или identity workload и успешную ротацию. Не публикуйте приватные ключи и чувствительные данные в логах или отчетах. Рабочий сертификат показывает, что стороны используют действующие удостоверения, выпущенные доверенным CA.
Проверить метрики, логи и ошибки Envoy
Анализируйте коды 5xx, connection reset, TLS handshake errors, upstream connection failures, состояние кластеров proxy и изменения latency. Сопоставляйте время ошибки с rollout и изменением политики. Рост TLS handshake errors после перехода указывает на несовместимость или проблему с сертификатом.
Проверить отказ plaintext-клиента в strict
В тестовой зоне выполните контролируемую проверку клиента без корректного mTLS и убедитесь, что соединение отклоняется ожидаемым образом. Проводите тест вне пользовательского трафика и с заранее подготовленным rollback. Такой тест подтверждает, что strict действительно принуждает к mTLS, а не работает как permissive из-за неверной области действия.
Сформировать финальный чеклист готовности
Включите пункты: все внутренние workload учтены, sidecar работают, сертификаты валидны, strict применен в ожидаемом scope, plaintext-соединения блокируются, ошибки в норме, внешние интеграции проверены, алерты настроены. Дополнительно изучите чек-лист проверки service mesh до rollout.
Типичные ошибки при смене permissive на strict и способы их исправления
Разбирайте ошибки в формате «симптом → вероятная причина → проверка → исправление». Это быстрее локализует проблему и не требует отключения mTLS во всем кластере.
503 и upstream connection failure после включения strict
Проверьте наличие proxy у клиента и сервера, примененную политику, порт и протокол, endpoint readiness, логи обоих sidecar и время начала ошибки. Не делайте вывод о проблеме приложения только по одному коду 503. Причина чаще всего в отсутствующем sidecar или неверном порте.
TLS handshake error и ошибки доверия к сертификату
Проверьте цепочку доверия, идентичности сторон, состояние Istiod, время на узлах, ротацию сертификатов и совместимость версий proxy. Ручное вмешательство в сертификаты без понимания модели CA создает скрытые сбои при ротации.
Strict включен не там или не для тех workload
Сопоставьте namespace, labels и фактические pod. Проверьте наличие более специфичных политик, revision Istio и результат доставки конфигурации до proxy. Ошибка selector часто приводит к тому, что strict применяется к чужому workload.
Скрытые клиенты без mesh-прокси
Проверьте cronjob, миграции, мониторинг, backup, админские скрипты, init-контейнеры, ingress/egress и сервисы вне Kubernetes. Для каждого определите готовый способ подключения или временный изолированный маршрут.
Когда выполнять rollback и как не превратить его в постоянный обход защиты
Rollback выполняйте по минимальной области: сначала workload или namespace, где зафиксирован ущерб, а не весь mesh. После восстановления доступности сохраните логи, определите причину, назначьте повторную проверку и ограничьте срок временного permissive. Постоянный обход защиты снижает ценность всей миграции.
Эксплуатация mTLS после миграции: сертификаты, политики и мониторинг
Включение mTLS не заканчивается на strict. Это постоянный процесс контроля идентичностей, конфигурации и поведения трафика.
Контролировать ротацию сертификатов и состояние CA
Настройте контроль сроков действия, ошибок выпуска и ротации. Проверяйте поведение после обновления control plane и добавления новых trust domain. Внезапный сбой из-за истекшего сертификата предотвращается алертом, а не ручной проверкой.
Не допустить появления workload вне защищенного контура
Контролируйте sidecar-инъекцию, admission-настройки, новые namespace, исключения и deployment-процессы. Введите проверку политики в CI/CD или процедуру приемки релиза. Иначе новый сервис без proxy может появиться после очередного деплоя.
Связать mTLS с авторизацией и мониторингом поведения
После подтверждения mTLS переходите к принципу least privilege: используйте идентичности workload для authorization policy, наблюдайте неожиданные связи и регулярно пересматривайте микросегментацию. Альтернативную модель без sidecar для части трафика можно сравнить в материале про Istio Ambient Mode.
FAQ: частые вопросы о mTLS в Kubernetes и Istio
Ответы краткие и прикладные. Точные поля и команды зависят от версии Istio и выбранной модели установки.
Нужно ли переписывать приложение для включения mTLS?
Обычно нет. Sidecar-proxy управляет mTLS от имени приложения. Исключения: нестандартная схема трафика, TLS внутри приложения, отсутствие proxy и внешние клиенты без mesh.
Чем permissive отличается от strict?
PERMISSIVE принимает mTLS и plaintext, используется для наблюдения и диагностики. STRICT требует mTLS и отклоняет неподготовленные соединения. PERMISSIVE не является финальной защитной конфигурацией.
Можно ли включить mTLS только для одного namespace или сервиса?
Да, политика применяется к namespace или workload через PeerAuthentication. Проверьте зависимости, которые выходят за выбранную область, иначе strict для одного сервиса может блокировать его клиентов.
Как понять, что проблема вызвана mTLS, а не приложением?
Коррелируйте время ошибки, логи приложения и proxy, состояние сертификатов, примененную конфигурацию и результаты контролируемого теста клиента. Если plaintext-клиент стабильно отклоняется, а mTLS-клиент проходит, это указывает на mTLS.
Что делать с сервисами вне Kubernetes или без sidecar?
Варианты: добавить совместимый proxy, использовать gateway, настроить отдельный защищенный канал или временно изолировать направление с четким сроком дальнейшей миграции. Универсальной одной настройки для смешанной инфраструктуры нет.
Итог: безопасный критерий готовности к strict
Перед глобальным strict подтвердите измеримые условия: карта зависимостей актуальна, sidecar есть у всех внутренних участников, сертификаты выдаются и ротируются, permissive не показывает скрытых клиентов, canary strict прошел без деградации, внешние интеграции учтены, мониторинг и rollback готовы.
Чеклист перед глобальным strict
- Резервная копия манифестов и конфигурации сохранена.
- Control plane и Istiod работают без ошибок выпуска сертификатов.
- Сертификаты действуют, цепочка доверия подтверждена.
- Sidecar внедрен и запущен у всех внутренних сервисов.
- Карта зависимостей актуализирована вместе с владельцами сервисов.
- Внешние и legacy-интеграции явно изолированы или переведены на proxy.
- Метрики 5xx, reset, handshake errors находятся в базовом диапазоне.
- Тестовый отказ plaintext-клиента подтвержден.
- Canary strict пройден без деградации.
- Rollback подготовлен и проверен.
Принцип безопасного внедрения
Сначала докажите наблюдаемостью, что сервисы совместимы, затем включите принуждение на минимальной области и только после этого расширяйте strict. Не оставляйте permissive без владельца и срока устранения оставшихся несовместимостей. Безопасность усиливается поэтапно, а доступность контролируется на каждом шаге.