Kafka через публичный интернет в Google Cloud: безопасность, архитектура и реальная стоимость доступа

Подключить внешнего клиента к Kafka-кластеру обычно сложнее, чем выдать ему URL и учётные данные. Клиент сначала обращается к bootstrap-адресу, получает метаданные, а затем устанавливает соединения с конкретными брокерами. Поэтому сетевой доступ должен работать не для одной точки входа, а для набора адресов, который меняется вместе с кластером.

Появившийся в Google Cloud Managed Service for Apache Kafka публичный доступ убирает необходимость обязательно проводить внешний клиент через VPC, VPN или прокси. Но сам протокол Kafka от этого не превращается в интернет-API. Команда получает ещё один сетевой путь, который нужно защищать, наблюдать и учитывать в модели затрат.

Что именно Google сделал публичным

В примечаниях к выпуску функция публичного кластера появилась 10 сентября 2026 года, а 17 сентября Google Cloud объявил её общедоступной.

При включении публичного доступа сервис выделяет внешние IPv4-адреса для bootstrap-адреса и брокеров. Существующие DNS-имена становятся доступными через публичное DNS-разрешение.

При этом частная сеть не исчезает:

• у кластера по-прежнему должна быть хотя бы одна подключённая подсеть;

• внутри VPC с подключённой подсетью те же DNS-имена разрешаются в частные адреса;

• снаружи они разрешаются в публичные адреса;

• внешний клиент может подключаться, не направляя трафик через подключённую подсеть.

Таким образом, публичный доступ — не замена существующей сетевой архитектуры, а дополнительная плоскость доступа. Внутренние сервисы могут продолжать работать через Private Service Connect (PSC), а отдельные внешние клиенты — через интернет. Подробная схема описана в документации по сетевой настройке.

Это разделение важно: включение публичного доступа не требует переводить весь клиентский трафик на публичный маршрут.

Почему одного публичного bootstrap-адреса недостаточно

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

Следовательно, внешняя сеть должна разрешать весь необходимый клиентский путь:

1. DNS-разрешение bootstrap-адреса.

2. Соединение с конечной точкой bootstrap-адреса.

3. Получение адресов брокеров из метаданных Kafka.

4. DNS-разрешение и соединение с каждым требуемым брокером.

5. Повторное подключение при изменении состава или адресов кластера.

Google предупреждает, что публичные IP-адреса кластера нельзя считать постоянными. Их набор может измениться или расшириться при масштабировании, а после выключения и повторного включения public access адреса изменятся.

Для настройки исходящих межсетевых экранов Google публикует специальные DNS-записи обнаружения типа A. Одна такая запись содержит не более 30 IP-адресов; для больших кластеров появляются дополнительные записи. Их назначение — помочь межсетевому экрану, поддерживающему правила на основе FQDN, обнаружить актуальные адреса.

Однако Kafka-клиент должен использовать именно bootstrap-адрес, а не записи обнаружения. Смешение этих двух назначений создаёт хрупкую конфигурацию: межсетевой экран может знать адреса брокеров, но клиент не должен самостоятельно обходить стандартный механизм обнаружения Kafka.

Для внешней сети рекомендуется разрешать:

• TCP/9092 для SASL;

• TCP/9192 для mTLS.

Практический вывод: если межсетевой экран партнёра принимает только статический список IP, подключение потребует процедуры обновления этого списка. Если он поддерживает FQDN-правила, discovery records позволяют автоматизировать процесс.

Public, PSC или собственный Kafka-кластер

Выбор сетевого пути следует начинать не с вопроса «можно ли открыть Kafka в интернет», а с расположения клиентов и границ доверия.

Внутренние сервисы: PSC остаётся исходным вариантом

Для приложений в GKE, Compute Engine или Cloud Run частное подключение через PSC сохраняет достижимость по частным IP. Для каждой подключённой VPC сервис создаёт endpoint для bootstrap-адреса и отдельные endpoints для брокеров. DNS-имена остаются одинаковыми, но разрешаются в адреса, локальные для соответствующей клиентской сети.

Это особенно полезно, когда клиенты уже находятся в Google Cloud. Публичный маршрут в таком случае редко устраняет достаточно сложности, чтобы оправдать дополнительную внешнюю поверхность атаки и интернет-трафик.

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

Внешние клиенты: публичный путь может быть проще

Если партнёр работает в другом облаке или в собственной инфраструктуре, подключение через интернет может оказаться рациональнее VPN, bastion-host или сложной связности между VPC.

Наиболее управляемый сценарий выглядит так:

• у партнёра есть фиксированный исходящий NAT CIDR;

• этот диапазон добавлен в список разрешённых диапазонов кластера;

• межсетевой экран партнёра отслеживает адреса брокеров через DNS-записи обнаружения;

• аутентификация использует короткоживущие токены или mTLS;

• Kafka ACL ограничивают доступ конкретными темами и группами потребителей.

При динамических исходящих IP удобство быстро исчезает. Изменение адреса превращается в заявку на изменение списка разрешённых диапазонов, а временное добавление широкого диапазона ухудшает модель безопасности.

Собственное размещение: контроль возвращает эксплуатационные обязанности

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

С другой стороны, управляемый сервис не снимает ответственность за:

• клиентские приложения;

• проектирование тем и ACL;

• управление идентичностями;

• планирование ёмкости;

• аварийное восстановление;

• наблюдаемость полного клиентского пути.

Кроме того, сервис не защищает от регионального отказа или одновременной потери двух зон. Для такого уровня устойчивости нужны два региональных кластера и механизм синхронизации, например MirrorMaker 2.0. Эти ограничения перечислены в обзоре Managed Service for Apache Kafka.

CIDR — только первый барьер

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

• только публично маршрутизируемые IPv4-диапазоны;

• маска от /16 до /32;

• не более 500 диапазонов;

• диапазоны не должны пересекаться;

• RFC 1918 и IPv6 не поддерживаются.

Фильтрация выполняется через Cloud Next Generation Firewall. Google прямо рекомендует не добавлять недоверенные диапазоны.

Это делает публичный доступ неудобным для клиентов с мобильными адресами, IPv6-only сетями или непредсказуемым операторским NAT. Формальная возможность подключить IoT-устройства или удалённые площадки ещё не означает, что каждое устройство должно напрямую работать с Kafka.

Для edge-сценария более реалистична схема с контролируемым шлюзом:

Устройства → локальный или региональный шлюз → фиксированный NAT IPv4 → Kafka

Шлюз агрегирует соединения, обеспечивает предсказуемый адрес источника и может отвечать за буферизацию. Документация не подтверждает, что прямой доступ подходит для произвольных ограниченных устройств, мобильных адресов или IPv6-only парков.

Публичный адрес не означает незашифрованный или анонимный доступ

Все клиентские соединения с Google Managed Kafka защищены TLS. Анонимный доступ не разрешён. Поэтому сам факт наличия публичного IP не равен открытому plaintext listener.

Но TLS и проверка IP не отвечают на вопрос, что аутентифицированный клиент имеет право делать. Для этого нужны идентичность и Kafka ACL.

Предпочтительный путь: WIF и SASL/OAUTHBEARER

Для клиентов в AWS, Azure или собственной инфраструктуре Google рекомендует Workload Identity Federation (WIF) вместе с SASL/OAUTHBEARER. Внешняя идентичность получает короткоживущий Google access token и действует от имени service account.

Такой подход снижает зависимость от долговечных секретов. SASL/PLAIN с ключом service account технически допустим, но Google не рекомендует его для рабочей среды из-за статических долгоживущих учётных данных.

mTLS для организаций с собственной PKI

mTLS не привязан к конкретному облачному поставщику и подходит компаниям с уже работающей PKI. Идентичность клиента определяется по Subject Name сертификата.

У этой модели есть важное ограничение: авторизация mTLS-клиентов выполняется через Kafka ACL, а не через роли Google Cloud IAM. Следовательно, процессы выпуска, отзыва и обновления сертификатов должны быть согласованы с правилами Kafka.

ACL нельзя откладывать

Если Kafka ACL не настроены, документированное поведение по умолчанию предоставляет всем аутентифицированным субъектам полный доступ.

Это опасная ловушка: команда может тщательно ограничить CIDR и настроить WIF, но после успешной аутентификации партнёр получит доступ ко всем темам и группам потребителей.

Минимальная модель должна ограничивать:

• разрешённые темы;

• операции чтения и записи;

• consumer groups;

• административные операции;

• отдельные principals для разных приложений и сред.

Сетевой диапазон отвечает на вопрос «откуда пришло соединение». Идентичность — «кто подключился». ACL — «что ему разрешено». Ни один из этих слоёв не заменяет остальные.

Отзыв доступа и повторная аутентификация

Удаление CIDR из allowlist применяется только к новым соединениям. Уже установленная Kafka-сессия не обязана немедленно завершиться.

Поэтому инструкция реагирования на инцидент не должна состоять из единственного шага «удалить IP партнёра». При компрометации нужно задействовать несколько уровней:

1. Удалить или сузить разрешённый CIDR-диапазон, чтобы остановить новые соединения.

2. Отключить или отозвать скомпрометированную идентичность и сертификат; для уже выданных токенов проверить доступный механизм инвалидирования и учитывать их срок жизни.

3. Ограничить либо удалить соответствующие Kafka ACL.

4. Проверить активность затронутых тем и consumer groups.

5. Оценить, какие данные клиент успел прочитать или записать.

6. Проверить фактическое время прекращения доступа на тестовом соединении.

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

Есть и ещё одна эксплуатационная особенность: Managed Kafka требует повторной SASL-аутентификации каждые 30 минут. Клиенты без поддержки re-authentication могут регулярно терять соединение; Google указывает Kafka client 2.2.0 как минимальную версию с соответствующей возможностью. Это следует проверять длительным тестом, а не короткой отправкой нескольких сообщений. Детали приведены в руководстве по устранению ошибок.

Наблюдаемость должна охватывать клиентский путь

У сервиса нет JMX API для метрик брокеров. Доступны метрики Cloud Monitoring и журналы брокеров в Cloud Logging, но они показывают только серверную часть.

Например, topic_error_count не охватывает все классы отказов. Ошибка авторизации может блокировать запись, не попадая в эту метрику, а недоступный брокер может вообще не успеть ответить.

Поэтому Google рекомендует дополнять серверные данные клиентскими метриками. В практический набор показателей стоит включить:

• ошибки аутентификации и авторизации;

• ошибки DNS и TLS;

• задержку запросов;

• тайм-ауты и повторные попытки;

• повторные подключения;

• размер локальной очереди производителя;

• отставание потребителей;

• ошибки обращения к отдельным брокерам.

Для публичного пути полезно отдельно отслеживать:

• изменения списка разрешённых диапазонов;

• изменения адресов брокеров;

• успешность DNS-разрешения из внешней сети;

• доступность TCP/9092 или TCP/9192;

• состояние исходящего NAT клиента;

• объём интернет-трафика;

• разрывы, совпадающие с 30-минутной повторной SASL-аутентификацией.

Cloud Audit Logs помогают расследовать изменения кластеров, тем, ACL и идентичностей. Но они не записывают операции produce и consume. Более того, Data Access logs для операций с метаданными по умолчанию отключены, пока команда явно их не включит. Назначение и ограничения аудита описаны в документации Cloud Audit Logs для Managed Kafka.

Иными словами, журналы плоскости управления показывают, кто изменил ACL, но не заменяют клиентскую телеметрию при расследовании чтения или записи сообщений.

TCO: считать нужно трафик и эксплуатационную работу

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

TCO = ресурсы кластера
    + хранение
    + межзонная репликация
    + стоимость клиентского сетевого пути
    + аварийное восстановление
    + инженерная и эксплуатационная работа

Общая для public и private часть

Коэффициент репликации 3 по умолчанию создаёт платный межзонный обмен независимо от клиентского пути. Пример со страницы цен: запись 10 GiB в одной зоне создаёт ещё 20 GiB передачи для двух дополнительных реплик. При цене $0,01/GiB это $0,20 межзонного трафика.

Переход с PSC на публичный endpoint не устраняет эту составляющую.

Переменная публичного пути

Для трафика от кластера к внешнему потребителю применяется стандартная цена Internet egress. В документации приведён ориентировочный диапазон от $0,08 до $0,023 за GiB в зависимости от направления и объёма.

Следовательно, публичные потребители с большим объёмом чтения могут изменить экономику решения даже при небольшом числе клиентов. Точную сумму нужно рассчитывать для конкретной географии и проверять по фактическому экспорту биллинга.

Переменная частного пути

Для PSC оплачивается обработка трафика между клиентом и брокером, расположенными в разных зонах, — ориентировочно от $0,004 до $0,01 за GiB в зависимости от топологии. Почасовая плата за endpoints для Managed Kafka указана как отменённая. Актуальные ставки следует проверять на страницах Managed Kafka pricing и VPC pricing.

Из этих диапазонов нельзя заранее вывести, что PSC всегда дешевле публичного доступа: результат зависит от зон клиентов, направления трафика, географии и объёма. Нужны измерения конкретной нагрузки.

Организационные расходы

Публичный путь добавляет работу, которая не видна в счёте за Kafka:

• учёт и обновление CIDR партнёров;

• автоматизация DNS и межсетевых экранов;

• выпуск и отзыв идентичностей или сертификатов;

• проектирование ACL;

• поддержка клиентских библиотек и повторной аутентификации;

• диагностика внешнего сетевого пути;

• учения по отзыву доступа;

• контроль интернет-трафика и аномалий стоимости.

Частный путь, в свою очередь, требует планирования подсетей, зон, IAM и DNS. Собственный Kafka-кластер добавляет обновления, замену брокеров, эксплуатационные инструменты и дежурства. Сравнение только цен вычислительных ресурсов будет неполным.

Отдельно стоит учитывать Kafka Connect. Его workers находятся в выделенной подсети, и для доступа в интернет им нужен Cloud NAT. Публичный endpoint другого Kafka-кластера не отменяет этого требования. Например, MirrorMaker, подключающийся к интернет-доступному Kafka, всё равно требует исходящего маршрута через Cloud NAT — это отмечено в документации по созданию Connect cluster.

Практические сценарии

Локальная разработка

Публичный кластер позволяет разработчику подключаться без bastion-host или прокси. Это действительно сокращает время до первого сообщения.

Но рабочая станция должна выходить через стабильный публичный IPv4, а клиент — поддерживать TLS, выбранный способ аутентификации и, при использовании SASL, повторную аутентификацию.

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

SaaS-партнёр в другом облаке

Это наиболее убедительный сценарий публичного доступа. Он работает, если стороны могут зафиксировать сетевой и идентификационный контракт:

• партнёр предоставляет стабильный NAT CIDR;

• изменение CIDR проходит по согласованной процедуре;

• исходящий межсетевой экран использует DNS-записи обнаружения;

• WIF/OAUTHBEARER или mTLS обеспечивает идентичность;

• ACL ограничивают темы и группы;

• обе стороны собирают клиентскую телеметрию.

Если партнёр не контролирует исходящие адреса, публичный endpoint может оказаться сложнее VPN или промежуточного шлюза.

IoT, магазины и телекоммуникационные площадки

Google перечисляет такие сценарии, но их пригодность зависит от сетевой топологии. Парк устройств должен иметь контролируемый агрегирующий шлюз или NAT с предсказуемым IPv4-диапазоном.

Прямое подключение отдельных устройств с меняющимися мобильными адресами, IPv6-only связностью, нестабильным каналом или сложным управлением сертификатами нельзя считать автоматически поддержанной архитектурой.

Как провести равный public/private эксперимент

Без измерений нельзя достоверно сравнить задержку, пропускную способность или стоимость двух путей. Эксперимент должен использовать одинаковую нагрузку и отличаться только сетью.

1. Зафиксировать модель угроз

До теста перечислите:

• защищаемые данные и темы;

• внешних участников и операторов;

• границы между клиентом, интернетом, Google Cloud и Kafka;

• способы кражи идентичности;

• риск слишком широкого CIDR;

• последствия ошибочных ACL;

• возможное чтение, запись или удаление данных;

• доступные способы ограничения ущерба.

2. Подготовить два одинаковых клиента

Один клиент размещается в подключённой VPC и работает через PSC. Второй — во внешней среде с контролируемым NAT и публичным доступом.

Они должны использовать:

• одинаковую версию Kafka client;

• одинаковые настройки производителя и потребителя;

• одинаковые темы и размер сообщений;

• одинаковую интенсивность нагрузки;

• сопоставимые идентичности и ACL.

3. Измерять не только среднюю задержку

Собирайте:

• p50, p95 и p99 задержки;

• пропускную способность;

• частоту повторных попыток и ошибок;

• тайм-ауты;

• отставание потребителей;

• количество повторных подключений;

• ошибки DNS, TLS и аутентификации;

• интернет-трафик или обработку данных PSC в биллинге;

• число ручных действий для поддержки каждого пути.

4. Провести испытания на изменение конфигурации

Нормальная работа — только половина проверки. Отдельно протестируйте:

• удаление и добавление CIDR;

• смену исходящего NAT-адреса клиента;

• обновление токена или сертификата;

• 30-минутную повторную аутентификацию;

• изменение публичных IP брокеров;

• обновление FQDN-правил межсетевого экрана;

• ошибочную ACL;

• недоступность одного из брокеров.

5. Заранее определить критерии выбора

Публичный доступ рационален, если одновременно выполняются условия:

• клиент физически находится вне подключаемой VPC;

• у него есть стабильный и контролируемый исходящий IPv4;

• WIF или mTLS можно встроить в жизненный цикл идентичностей;

• ACL ограничивают доступ до необходимого минимума;

• межсетевой экран способен учитывать изменения адресов брокеров;

• команда наблюдает клиентский путь;

• стоимость интернет-трафика приемлема;

• процедура отзыва доступа проверена практически.

Если клиент уже работает внутри Google Cloud, частное подключение через PSC остаётся более сильной исходной архитектурой. Публичный доступ лучше рассматривать как ограниченный и сегментированный путь для тех клиентов, которых действительно невозможно или нерационально подключить к VPC, а не как новый способ подключения всех приложений к Kafka.