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 для безопасности
- Автоматический mTLS — шифрование и аутентификация всех межсервисных соединений без изменения кода
- Авторизация на уровне сервисов (AuthorizationPolicy) — какой сервис может вызывать какой
- Наблюдаемость — метрики, логи, трассировки для всего трафика
- Rate Limiting — ограничение запросов между сервисами
- Ротация сертификатов — автоматическая, без простоя
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, авторизация, ротация сертификатов).