Налаштування 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, моніторячи метрики помилок. Пакетний переклад усього кластера за раз регулярно закінчується інцидентом. Вартість розраховується індивідуально після аудиту архітектури.

Пишіть — оцінимо ваш проект і запропонуємо оптимальне рішення.