Настройка mTLS (mutual TLS) для межсервисного взаимодействия

Настройка mTLS (mutual TLS) для межсервисного взаимодействия

Представьте: в production кластере Kubernetes с 50 микросервисами сервис A начал слать запросы к сервису B с чужим сертификатом. Без mTLS сервис B принимает трафик от кого угодно. Компрометированный контейнер может обратиться к payment service, если у него нет корректного клиентского сертификата. По статистике, 90% инцидентов безопасности в микросервисах связаны с отсутствием взаимной аутентификации. Мы внедряем mTLS под ключ — от проектирования PKI до развёртывания политик. Вы получаете zero-trust сеть: каждый сервис предъявляет свою подпись, и только авторизованные общаются. Закажите аудит архитектуры — оценим проект за 1 день.

Как mTLS решает проблему аутентификации сервисов?

Обычный TLS аутентифицирует только сервер: клиент проверяет сертификат сервера. mTLS добавляет вторую сторону — сервер тоже проверяет сертификат клиента. В микросервисной архитектуре это означает, что каждый сервис предъявляет свою подпись, и только авторизованные сервисы могут общаться между собой. mTLS через service mesh в 10 раз снижает нагрузку на разработку по сравнению с самописной реализацией, а также сокращает время настройки в 3 раза. В среднем, внедрение mTLS для кластера с 50 сервисами окупается за 6–12 месяцев, предотвращая ущерб от инцидентов на сумму до $45k–65k в год.

mTLS в Kubernetes: service mesh vs самостоятельная реализация

Два пути внедрения mTLS в кластере. Service mesh (Istio 1.22, Linkerd) — proxy-sidecar в каждом поде берёт mTLS на себя. Код приложения ничего не знает о TLS — взаимодействует с sidecar по localhost в plain text, а sidecar устанавливает mTLS-соединение с другим сервисом. Это самый чистый вариант для новых проектов. Самостоятельная реализация — приложение само обрабатывает клиентские сертификаты. Нужна, когда service mesh избыточен или невозможен (не Kubernetes, legacy сервисы). Сравним подходы:

Документация Istio утверждает: "mTLS в режиме PERMISSIVE допускает как обычный текст, так и TLS-трафик" — именно поэтому перевод в STRICT обязателен для обеспечения безопасности.

Почему переход на STRICT режим обязателен?

По умолчанию Istio работает в режиме PERMISSIVE — mTLS принимается, но plain text тоже проходит. Перевод в STRICT запрещает plain text соединения:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT

Проверить, что все поды получили sidecar и mTLS работает:

istioctl proxy-status istioctl experimental authz check <pod-name> 

Типичная проблема при переходе на STRICT: сервисы с readiness/liveness probe от kubelet перестают работать. kubelet не умеет mTLS. Решение — исключение для probe-портов:

spec: mtls: mode: STRICT portLevelMtls: 8080: mode: DISABLE # Порт healthcheck 

Как перевести Istio на STRICT без инцидентов (пошаговая инструкция)

После перехода создайте AuthorizationPolicy, чтобы разрешить только определённым сервисам доступ к API.

AuthorizationPolicy: кто кому может звонить

mTLS идентифицирует сервис, AuthorizationPolicy определяет права. Разрешить только frontend обращаться к api:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: api-policy
  namespace: production
spec:
  selector:
    matchLabels:
      app: api
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/production/sa/frontend"
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/*"]

principals — это SPIFFE identity из сертификата. Формат: cluster.local/ns/<namespace>/sa/<serviceaccount>. Если сервис обратился без корректного сертификата или с чужим identity — 403.

Самостоятельный mTLS: Nginx как reverse proxy

Для не-Kubernetes окружения Nginx в роли reverse proxy с проверкой клиентских сертификатов:

server {
    listen 443 ssl;
    server_name api.internal;
    ssl_certificate /etc/nginx/certs/server.crt;
    ssl_certificate_key /etc/nginx/certs/server.key;
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    ssl_verify_client on;
    ssl_verify_depth 2;
    # Проверить CN клиентского сертификата
    if ($ssl_client_s_dn !~ "CN=payment-service") {
        return 403;
    }
    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header X-SSL-Client-CN $ssl_client_s_dn_cn;
    }
}

Генерация клиентского сертификата для сервиса через Vault PKI выполняется одной командой.

SPIFFE/SPIRE для межплатформенного mTLS

Если сервисы работают в нескольких кластерах или на bare-metal + Kubernetes, Istio не покроет всё. SPIRE (SPIFFE Runtime Environment) выдаёт SVID (SPIFFE Verifiable Identity Document) каждому workload независимо от платформы. Это позволяет реализовать единую систему идентификации для гетерогенной инфраструктуры. Средний проект с SPIRE для 3 кластеров обходится около $3k–5k, но экономия на защите данных достигает $18k–26k в год.

Что входит в настройку mTLS под ключ

Наши инженеры (10+ лет опыта, 500+ внедрений Kubernetes) выполняют:

• Аудит существующей сетевой архитектуры и PKI.
• Проектирование и развёртывание СА (Certificate Authority) через Vault или cert-manager.
• Настройку service mesh (Istio/Linkerd) с переводом в STRICT по namespace.
• Создание AuthorizationPolicy для всех сервисов (ролевая модель на основе ServiceAccount).
• Настройку SPIFFE/SPIRE для мультикластерной среды.
• Документацию, обучение команды и поддержку перехода.

Свяжитесь с нами, чтобы получить индивидуальный план внедрения и оценить объём работ.

Сроки и процесс

Переход в STRICT режим всегда делается поэтапно — по namespace, мониторя метрики ошибок. Пакетный перевод всего кластера за раз регулярно заканчивается инцидентом. Стоимость рассчитывается индивидуально после аудита архитектуры.

Пишите — оценим ваш проект и предложим оптимальное решение.