Gymterview
senior

Что такое Service Mesh и как он обеспечивает безопасность?

Service Mesh — инфраструктурный слой, управляющий межсервисным взаимодействием в микросервисной архитектуре через sidecar-прокси (Envoy), которые внедряются в каждый под и перехватывают весь сетевой трафик.

Основные реализации

Решение Описание
Istio Наиболее функциональный, использует Envoy, поддержка Google
Linkerd Легковесный, написан на Rust (прокси), проще в эксплуатации
Consul Connect От HashiCorp, интегрируется с Consul для service discovery

Архитектура Service Mesh (Istio)

Пример
┌──────────────── Control Plane (istiod) ─────────────────┐
│  Pilot (конфигурация маршрутов)                          │
│  Citadel (управление сертификатами, mTLS)                │
│  Galley (валидация конфигурации)                         │
└─────────────────────────────────────────────────────────┘
         │                              │
    ┌────▼─────────────┐     ┌──────────▼──────────┐
    │  Pod              │     │  Pod                 │
    │ ┌───────────────┐ │     │ ┌──────────────────┐ │
    │ │ payment-svc   │ │     │ │ account-svc      │ │
    │ └───────┬───────┘ │     │ └───────┬──────────┘ │
    │ ┌───────▼───────┐ │     │ ┌───────▼──────────┐ │
    │ │ Envoy sidecar │◄────►│ │ Envoy sidecar    │ │
    │ └───────────────┘ │     │ └──────────────────┘ │
    └───────────────────┘     └──────────────────────┘
          mTLS-соединение

Автоматический mTLS между сервисами

Пример
# Istio PeerAuthentication: включение mTLS для всего mesh
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
Пример
# Разрешить трафик только от конкретных сервисов
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: payment-policy
  namespace: payment
spec:
  selector:
    matchLabels:
      app: payment-service
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/gateway/sa/api-gateway"
      to:
        - operation:
            methods: ["POST"]
            paths: ["/api/transfers/*"]

Возможности Service Mesh для безопасности

  1. Автоматический mTLS — шифрование и аутентификация всех межсервисных соединений без изменения кода
  2. Авторизация на уровне сервисов (AuthorizationPolicy) — какой сервис может вызывать какой
  3. Наблюдаемость — метрики, логи, трассировки для всего трафика
  4. Rate Limiting — ограничение запросов между сервисами
  5. Ротация сертификатов — автоматическая, без простоя

Linkerd (более простая альтернатива)

Пример
# Установка
curl -sL https://run.linkerd.io/install | sh
linkerd install | kubectl apply -f -

# Добавление sidecar к деплойменту
kubectl get deploy payment-service -o yaml | linkerd inject - | kubectl apply -f -

# Проверка mTLS
linkerd viz edges deployment -n payment

Service Mesh решает ключевую задачу — обеспечивает шифрование и аутентификацию трафика между микросервисами автоматически, без необходимости настраивать TLS в каждом сервисе вручную.

На собеседовании: интервьюер хочет услышать про sidecar-паттерн, автоматический mTLS и AuthorizationPolicy. Частая ошибка — описывать Service Mesh только как «маршрутизатор» и не упомянуть его роль в обеспечении безопасности (mTLS, авторизация, ротация сертификатов).