В предыдущей статье мы на примере нашего облачного сервиса разобрали базовые принципы работы сервисов в Istio и рассмотрели ключевые подходы к обеспечению безопасности в облачной среде.

Наш продукт представляет собой консоль управления базами данных, поэтому значительная часть его архитектуры построена вокруг взаимодействия микросервисов с СУБД. Именно этот контур лежит в основе большинства операций — от управления и администрирования до мониторинга и обслуживания, — а значит, требования к его надёжности и безопасности становятся критически важными.

В этом контексте особенно интересен вопрос организации взаимодействия сервисов с внешними базами данных. В статье мы сосредоточимся на этом прикладном аспекте и рассмотрим его на примере PostgreSQL. В качестве технологической основы будем использовать Platform V Synapse Service Mesh — решение СберТеха для управления микросервисным взаимодействием в Kubernetes-кластерах, созданное на основе Istio и Envoy. Synapse Service Mesh представляет собой отдельный инфраструктурный слой, позволяющий централизованно управлять трафиком, безопасностью, наблюдаемостью сервисов и политиками взаимодействия между ними.

Мы разберём, какие архитектурные и эксплуатационные сценарии здесь возможны, а также покажем, как можно делегировать задачи обеспечения безопасности с уровня приложения на уровень инфраструктуры, используя возможности Synapse.

Ранее мы уже затрагивали сценарий взаимодействия облачного микросервиса с СУБД PostgreSQL в режиме passthrough, при котором обеспечение безопасности соединения полностью ложится на приложение — получается сквозное TLS-соединение до сервера СУБД. Предлагаю начать погружение именно с этого базового сценария.

Для наглядности воспроизведём ранее рассмотренный сценарий. Для этого необходимо подготовить следующий набор CRD (Custom Resource Definition):

1. ServiceEntry — регистрирует внешний сервис в реестре mesh и позволяет управлять трафиком к нему;

2. Service — определяет внутреннюю точку входа в Egress Gateway;

3. Gateway — описывает конфигурацию самого Egress Gateway и принимает входящий трафик;

4.  VirtualService — управляет маршрутизацией трафика внутри mesh и через gateway;

5. DestinationRule — задаёт политики обработки трафика, включая TLS и поведение для конкретных subsets.

ServiceEntry

---
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: postgres-se-passthrough
spec:
  endpoints:
    - address: 10.40.20.72
  exportTo:
    - .
  hosts:
    - postgres.solution.test
  location: MESH_EXTERNAL
  ports:
    - name: tcp-5432
      number: 5432
      protocol: tcp
  resolution: STATIC

В этой конфигурации создаётся запись в реестре Istio для внешнего сервиса PostgreSQL — он зарегистрирован под статически указанным доменным именем postgres.solution.test (IP: 10.40.20.72) и принимает подключения через порт 5432 (TCP). С этого момента трафик к этому сервису будет отслеживаться и управляться Istio. 

Service

---
kind: Service
apiVersion: v1
metadata:
  name: postgres-egress-service-passthrough
spec:
  ports:
    - name: tcp-5000
      protocol: TCP
      port: 5000
      targetPort: 5000
  type: ClusterIP
  selector:
    app: egressgateway

Следующим этапом определяем порт 5000 (TCP), через который в Egress Gateway будут обрабатываться подключения наших внутренних сервисов к СУБД.

Gateway

С помощью Gateway добавим точку входа для трафика, поступающего на Egress Gateway:

---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: postgres-gw-passthrough
spec:
  selector:
    app: egressgateway
  servers:
    - hosts:
        - postgres.solution.test
      port:
        name: tcp-5000
        number: 5000
        protocol: TCP

Конфигурация создаёт ресурс Gateway, который принимает входящий TCP-трафик через порт 5000 для хоста postgres.solution.test (IP: 10.40.20.72). Трафик обрабатывается в режиме passthrough: между микросервисом и СУБД настраивается защищённый канал передачи данных со сквозным шифрованием.

VirtualService

---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: postgres-vs-passthrough
spec:
  exportTo:
    - .
  gateways:
    - postgres-gw-passthrough
    - mesh
  hosts:
    - postgres.solution.test
  tcp:
    - match:
        - gateways:
            - mesh
          port: 5432
      route:
        - destination:
            host: postgres-egress-service-passthrough
            port:
              number: 5000
            subset: postgres-internal-passthrough
    - match:
        - gateways:
            - postgres-gw-passthrough
          port: 5000
      route:
        - destination:
            host: postgres.solution.test
            port:
              number: 5432
            subset: postgres-external-passthrough

Созданный VirtualService управляет маршрутизацией TCP-трафика: все запросы, адресованные хосту СУБД, зарегистрированному в Istio под именем postgres.solution.test на порт 5432 (TCP), через сервисную сеть перенаправляются на внутренний порт 5000 (TCP) граничного прокси. После чего трафик, поступающий на порт 5000 (TCP) граничного прокси, маршрутизируется на адрес хоста (IP: 10.40.20.72) и порт 5432 (TCP).

DestinationRule

В заключение определим ресурсы правила DestinationRule для каждого потока трафика:

• DestinationRule (internal) устанавливает политики обработки трафика от микросервиса к Egress Gateway (subset postgres-internal-passthrough);

• DestinationRule (external) устанавливает политики обработки трафика от Egress Gateway к сервису СУБД (subset postgres-external-passthrough).

---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: postgres-external-dr-passthrough
spec:
  exportTo:
    - .
  host: postgres.solution.test
  subsets:
    - name: postgres-external-passthrough
  workloadSelector:
    matchLabels:
      app: egressgateway

Перейдём к демонстрации. Для этого будем использовать psql-клиент, запущенный внутри пода приложения, тем самым имитируя поведение прикладного PostgreSQL-клиента, и рассмотрим процесс установления защищённого TLS-соединения посредством проксирования трафика через Egress Gateway в режиме passthrough.

Чтобы не отвлекаться на подготовительные шаги, предположим, что тестовый клиентский сервис уже развёрнут в облаке, корректные клиентские и серверные сертификаты выпущены, а все необходимые для демонстрации артефакты доставлены в файловые системы клиента и сервера.

В качестве политики доступа к серверу СУБД PostgreSQL будем использовать специальную конфигурацию pg_hba.conf:

hostssl all all 0.0.0.0/0 cert

Эта запись означает следующее:

• hostssl — подключение разрешено только по защищённому каналу;

• all all — допускаются любые базы данных и пользователи;

• 0.0.0.0/0 — подключение возможно с любого IP-адреса;

•  cert — аутентификация выполняется по клиентскому сертификату. Это ключевой аспект проверки работоспособности аутентификации в нашей схеме.

В нашем примере это означает, что для успешного подключения клиент должен:

1. установить TLS-сессию;

2. предоставить корректный сертификат, подписанный доверенным удостоверяющим центром;

3. использовать имя пользователя, соответствующее Common Name (CN) сертификата.

Формат команды для подключения к БД, который будем использовать в базовом примере:

psql "host=<db_host> \
      port=<db_port> \
      dbname=<db_name> \
      user=<db_user>  \
      sslmode=<db_sslmode> \
      sslrootcert=<db_sslrootcert>  \
      sslcert=<db_sslcert> \
      sslkey=<db_sslkey>"

Где:

• host — адрес PostgreSQL-сервера;

• port — TCP-порт PostgreSQL;

• dbname — имя базы данных внутри PostgreSQL;

• user — имя пользователя PostgreSQL;

• sslmode — режим использования TLS:

  • disable — соединение устанавливается без использования TLS/SSL, данные передаются в открытом виде;

  • allow — клиент сначала пытается подключиться без шифрования, но при необходимости допускает использование SSL.

  • prefer — по умолчанию используется SSL-соединение, однако при его недоступности допускается переход на нешифрованный канал.

  • require — SSL обязателен: соединение устанавливается только при наличии защищённого канала, но сертификат сервера не проверяется.

  • verify-ca — SSL обязателен, при этом дополнительно проверяется, что сертификат сервера подписан доверенным удостоверяющим центром (CA).

  • verify-full — наиболее строгий режим: проверяется как доверие к CA, так и соответствие имени хоста в сертификате адресу сервера. Это обеспечивает полноценную защиту от подмены сервера.

• sslrootcert — сертификат доверенного удостоверяющего центра;

• sslcert — клиентский сертификат;

• sslkey — приватный ключ клиента.

Подключимся к серверу PostgreSQL с подстановкой соответствующих значений параметров:

10001@psql-66f8cccd88-lhb58:/$ psql "host=postgres.solution.test user=postgres port=5432 sslmode=verify-full sslcert=/tmp/certs/postgres.crt sslkey=/tmp/certs/postgres.key sslrootcert=/tmp/certs/ca.crt"

SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)

Проверим фактические значения параметров установленного соединения средствами самой СУБД:

postgres=# SELECT ssl, version, cipher
FROM pg_stat_ssl
WHERE pid = pg_backend_pid();

Результат:

 ssl | version |         cipher         
-----+---------+------------------------
 t   | TLSv1.3 | TLS_AES_256_GCM_SHA384
(1 row)

При установлении сессии успешно прошла взаимная криптографическая проверка: сервер подтвердил свою подлинность с использованием сертификата, проверенного через доверенный корневой центр, а клиент аутентифицировался посредством собственного сертификата и приватного ключа, что соответствует модели mTLS.

Дополнительно подтверждена маршрутизация трафика через Egress Gateway:

[2026-04-23T17:52:44.346Z] "- - -" 0 - - - "-" 2706 3577 13828 - "-" "-" "-" "-" "10.40.20.72:5432" outbound|5432| |postgres.solution.test 172.21.16.23:45806 172.21.16.23:5000 172.21.18.58:37264 - -

Формат логов Egress Gateway мы подробно разбирали в предыдущей статье, поэтому здесь обратим внимание только на ключевые элементы:

• outbound|5432|postgres-external-passthrough|postgres.solution.test — указывает на используемый subset и подтверждает, что применилось нужное правило маршрутизации;

• 172.21.16.23:5000 — внутренний адрес и порт Egress Gateway, через который прошёл трафик.

В этом сценарии вся ответственность за установление защищённого соединения полностью ложится на приложение. Поэтому сервис должен:

1. знать, где размещены сертификаты и ключи;

2. корректно использовать их при установлении соединения;

3. управлять параметрами TLS (режим, проверка, цепочка доверия);

4. обеспечивать корректную обработку ошибок при работе с защищённым соединением.

На практике это приводит к ряду сложностей.

Во-первых, конфигурация начинает дублироваться от сервиса к сервису: каждый клиент, взаимодействующий с PostgreSQL, должен иметь собственный набор настроек и артефактов.

Во-вторых, усложняется управление сертификатами:

• необходимо доставлять их в каждый под;

• контролировать сроки действия;

• обеспечивать ротацию и актуальность.

В-третьих, возрастает риск ошибок конфигурации. Любая неточность — от неверного пути к сертификату до некорректных параметров TLS — может привести либо к отказу соединения, либо, что хуже, к снижению уровня безопасности. В результате с ростом числа микросервисов увеличивается количество конфигурации, артефактов и точек отказа, что делает такой подход всё менее управляемым.

Возникает закономерный вопрос: можно ли освободить приложение от этих задач и переложить ответственность за установление защищённого соединения на инфраструктуру? Возможности Istio позволяют реализовать такой подход с помощью делегирования TLS на уровень Egress Gateway.

Теперь рассмотрим, как эта же задача решается в сценарии с использованием продукта СберТеха — Platform V Synapse Service Mesh. Это enterprise-версия Istio, которая обладает расширенными возможностями и поддерживает дополнительные протоколы. В нашем случае мы рассмотрим нативную поддержку протокола PostgreSQL, которая доступна исключительно в Synapse. Сам сценарий без изменений: мы сохраняем то же подключение, но переносим точку инициализации TLS-соединения на Egress Gateway. Сертификаты больше не находятся в поде приложения — они размещаются и управляются на уровне инфраструктуры. Посмотрим, как это сделано в Synapse, и подключим микросервис к СУБД PostgreSQL.

Аналогично вышеописанному примеру определим выделенный порт 5001 (TCP), через который в Egress Gateway будут обрабатываться подключения наших внутренних сервисов к СУБД:

---
kind: Service
apiVersion: v1
metadata:
  name: postgres-egress-service-tls-origin
spec:
  ports:
    - name: tcp-5001
      protocol: TCP
      port: 5001
      targetPort: 5001
  type: ClusterIP
  selector:
    app: egressgateway

С помощью Gateway добавим точку входа для трафика, поступающего в Egress Gateway:

---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: postgres-gw-tls-origin
spec:
  selector:
    app: egressgateway
  servers:
    - hosts:
        - postgres.solution.test
      port:
        name: postgres-5001
        number: 5001
        protocol: TCP

Конфигурация создаёт ресурс Gateway, который принимает входящий TCP-трафик через порт 5001 для хоста postgres.solution.test (IP: 10.40.20.72).

С помощью VirtualService создаём необходимые правила маршрутизации TCP-трафика: все запросы, адресованные хосту СУБД, зарегистрированному в Istio под именем postgres.solution.test на порт 5432 (TCP), через сервисную сеть перенаправляются на внутренний порт 5001 (TCP) граничного прокси. После чего трафик, поступающий на порт 5001 (TCP) граничного прокси, маршрутизируется на адрес хоста postgres.solution.test (IP: 10.40.20.72) и порт 5432 (TCP):

---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: postgres-vs-tls-origin
spec:
  exportTo:
    - .
  gateways:
    - postgres-gw-tls-origin
    - mesh
  hosts:
    - postgres.solution.test
  tcp:
    - match:
        - gateways:
            - mesh
          port: 5432
      route:
        - destination:
            host: postgres-egress-service-tls-origin
            port:
              number: 5001
            subset: postgres-internal-tls-origin
    - match:
        - gateways:
            - postgres-gw-tls-origin
          port: 5001
      route:
        - destination:
            host: postgres.solution.test
            port:
              number: 5432
            subset: postgres-external-tls-origin

Определим ресурсы правила DestinationRule для внутреннего и внешнего потоков трафика:

DestinationRule (internal)

---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: postgres-internal-dr-tls-origin
spec:
  exportTo:
    - .
  host: postgres-egress-service-tls-origin
  subsets:
    - name: postgres-internal-tls-origin

DestinationRule (external)

---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: postgres-external-dr-tls-origin
spec:
  exportTo:
    - .
  host: postgres.solution.test
  subsets:
    - name: postgres-external-tls-origin
      trafficPolicy:
        tls:
          caCertificates: /secrets/istio/egressgateway-certs/ca.crt
          clientCertificate: /secrets/istio/egressgateway-certs/postgres.crt
          privateKey: /secrets/istio/egressgateway-certs/postgres.key
          mode: MUTUAL
  workloadSelector:
    matchLabels:
      app: egressgateway

В отличие от предыдущего примера дополнительно необходимо определить значения параметров TLS-соединения, с использованием которых будем создавать защищённый транспорт к внешнему сервису СУБД PostgreSQL.

В итоге схема заработала, регистрируем внешний сервис в реестре Istio:

---
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: postgres-se-tls-origin
spec:
  endpoints:
    - address: 10.40.20.72
  exportTo:
    - .
  hosts:
    - postgres.solution.test
  location: MESH_EXTERNAL
  ports:
    - name: postgres-5432
      number: 5432
      protocol: postgres
  resolution: STATIC

Здесь важно обратить внимание на параметр protocol: postgres. На первый взгляд он может показаться эквивалентным TCP, однако в контексте Platform V Synapse Service Mesh это принципиально разные режимы работы.

Если в конфигурации используется protocol: tcp, то Service Mesh воспринимает трафик как непрозрачный поток данных. В этом режиме:

• sidecar и Egress Gateway не обладают информацией о протоколе;

• соединение не анализируется; 

• либо TLS полностью реализуется на стороне приложения, либо инициируется прокси без учёта особенностей протокола.

Фактически Service Mesh выступает в роли L4-прокси, который просто передаёт байты между источником и получателем. Чтобы подтвердить это поведение, проанализируем сетевой трафик между Egress Gateway и сервером PostgreSQL. 

В дампе есть такая последовательность:

• после установления TCP-соединения Egress Gateway сразу инициирует TLS handshake (Client Hello);

• при этом отсутствует предварительный этап SSL negotiation, характерный для PostgreSQL;

• сервер PostgreSQL разрывает соединение (RST), так как ожидает SSLRequest перед началом TLS.

Эта последовательность соответствует некорректному сценарию, представленному на диаграмме слева:

Это говорит о нарушении протокола: TLS-сессия инициируется без предварительного этапа SSLRequest и уже после начала PostgreSQL-взаимодействия. В результате в одном соединении смешиваются два несовместимых состояния: plaintext PostgreSQL и попытка перехода в TLS, что приводит к разрыву соединения.

Это подтверждает, что в режиме protocol: tcp:

• управление TLS остаётся на уровне приложения;

• инфраструктура не может корректно встроиться в установление соединения;

• возможности централизованного управления безопасностью ограничены.

При использовании protocol: postgres поведение меняется.

Synapse Service Mesh начинает рассматривать трафик как PostgreSQL-соединение и получает дополнительный контекст, позволяющий:

• корректно обрабатывать этап установления соединения; 

• учитывать особенности PostgreSQL handshake (инициализация соединения, обмен параметрами сессии и переход в TLS через SSLRequest); 

• инициировать TLS-сессию на стороне Egress Gateway; 

• применять параметры безопасности, заданные в DestinationRule.

В отличие от предыдущего сценария, корректная последовательность взаимодействия выглядит следующим образом:

• устанавливается TCP-соединение;

• Egress Gateway инициирует SSLRequest;

• сервер PostgreSQL подтверждает возможность перехода в TLS;

• устанавливается TLS-сессия;

• после этого передаётся StartupMessage и начинается аутентификация.

Таким образом, благодаря protocol: postgres становится возможной следующая модель:

1. приложение устанавливает обычное TCP-соединение (sslmode=disable); 

2. sidecar направляет трафик через Egress Gateway; 

3. Egress Gateway инициирует TLS-сессию с PostgreSQL; 

4. используются сертификаты, управляемые на уровне инфраструктуры.

Теперь вернёмся к нашему примеру и посмотрим, как это отражается на уровне приложения. С точки зрения приложения подключение упрощается:

psql "host=postgres.solution.test user=postgres port=5432 sslmode=disable"

Обратите внимание на значение параметра sslmode=disable: подключение из пода приложения происходит с отключением шифрования в явном виде.

Выполним команду и проанализируем результат:

10001@psql-a-6d5669b5d-ztf4g:/$ psql "host=postgres.solution.test user=postgres port=5432 sslmode=disable"

postgres=# SELECT ssl, version, cipher
FROM pg_stat_ssl
WHERE pid = pg_backend_pid();
 ssl | version |           cipher            
-----+---------+-----------------------------
 t   | TLSv1.2 | ECDHE-RSA-AES256-GCM-SHA384
(1 row)

Установлено защищённое подключение, несмотря на то, что на уровне приложения TLS явно отключён через sslmode=disable. То есть sidecar-прокси перехватывает исходящий трафик, направляет его через Egress Gateway, где и происходит установление TLS-сессии с использованием необходимых сертификатов.

[2026-04-23T18:01:09.986Z] "- - -" 0 - - - "-" 89 510 10977 - "-" "-" "-" "-" "10.40.20.72:5432" outbound|5432|postgres-internal-tls-origin|postgres.solution.test 172.21.16.23:51452 172.21.16.23:5001 172.21.11.129:39034 – 

Фиксируем ключевые моменты:

• outbound|5432|postgres-internal-tls-origin|postgres.solution.test — указывает на используемый subset и подтверждает, что применилось нужное правило маршрутизации;

• 172.21.16.23:5001 — внутренний адрес и порт Egress Gateway, через который прошёл трафик.

Дополнительно проверим негативный сценарий. Для настроенного транспорта попытаемся подключиться с именем технического пользователя, не соответствующим Common Name сертификата, используемого Egress Gateway при аутентификации на сервере СУБД.

10001@psql-a-6d5669b5d-ztf4g:/$ psql "host=postgres.solution.test user=kintsugi port=5432 sslmode=disable dbname=postgres"

psql: error: connection to server at "postgres.solution.test" (10.40.20.72), port 5432 failed: FATAL:  certificate authentication failed for user "kintsugi"

В этом случае соединение ожидаемо не устанавливается из-за ошибки проверки клиентского сертификата на стороне PostgreSQL на этапе TLS-handshake.

В результате приложение полностью освобождается от задач, связанных с TLS: оно не управляет сертификатами, не хранит конфиденциальные артефакты и не участвует в установлении защищённого соединения.

Хотя на уровне клиента TLS явно отключён через sslmode=disable, фактически соединение устанавливается в защищённом режиме благодаря тому, что sidecar-прокси перенаправляет трафик на Egress Gateway, где инициализируется TLS-сессия с PostgreSQL. Это дополнительно подтверждается логами Egress Gateway, где видно, что трафик маршрутизируется через соответствующий subset и завершается установлением защищённого соединения. При попытке использования некорректного клиентского сертификата соединение отклоняется на этапе TLS-handshake на стороне PostgreSQL, что подтверждает корректность модели аутентификации.

Однако, как и любое архитектурное решение, эта схема имеет особенности и ограничения, которые важно учитывать при проектировании.

При использовании Egress Gateway в качестве точки установления TLS-соединения шифрование выполняется не на стороне приложения, а на промежуточном узле, поэтому:

• соединение между приложением и Egress Gateway может передаваться в незашифрованном виде (в зависимости от настроек Service Mesh);

• Egress Gateway становится доверенной точкой, имеющей доступ к трафику в открытом виде;

• нарушается модель сквозного шифрования (end-to-end TLS).

В сценариях, где передаются конфиденциальные данные, такой подход требует дополнительной оценки рисков и, как правило, уступает классической модели прямого TLS-соединения от приложения до сервера СУБД. Для таких каналов рекомендуется использовать именно сквозное шифрование без промежуточной терминации TLS.

Второе ограничение связано с особенностями модели маршрутизации в Istio: для одного host:port можно применить только одну транспортную политику. Это означает, что невозможно одновременно использовать различные режимы проксирования (например, разные TLS-настройки или протоколы) для одного и того же сетевого endpoint. На практике это ограничивает гибкость конфигурирования и требует либо введения дополнительных портов, либо логического разделения сервисов на уровне сети.

Рассмотренный пример описывает взаимодействие одного сервиса с сервером СУБД. Однако в реальных системах ситуация, как правило, значительно сложнее: в облачной среде одновременно работает множество сервисов, каждый из которых использует собственные учётные данные для доступа к базе данных. Здесь начинают проявляться ограничения рассмотренного подхода, связанные с маршрутизацией TCP-трафика и выбором TLS-политик.

В следующей части мы подробно разберём, какие сложности возникают при масштабировании этого решения и как их можно обойти, используя механизмы маршрутизации в Service Mesh.

Все примеры представленных конфигураций можно найти в моём репозитории.

Спасибо за внимание!