Назад | Перейти на главную страницу

Как создать правило брандмауэра GPC для разрешения трафика между кластерами GKE

Задний план

У меня есть проект GCP с двумя кластерами GKE: public-cluster и private-cluster. public-cluster запускает шлюз API, который выполняет централизованную аутентификацию, ведение журнала, ограничение скорости и т. д. и перенаправляет запросы на серверные микросервисы, работающие на private-cluster. Шлюз API построен с использованием Оцелот.

public-cluster имеет выход в Интернет и использует ingress-nginx для предоставления общедоступного внешнего IP-адреса, который принимает трафик HTTP / s на портах 80/443.

Намерение для private-cluster это может принимать трафик порта 80/443 только от public-cluster. Мы не хотим, чтобы этот кластер был доступен откуда-либо еще, т.е. никаких прямых HTTP / s-запросов к private-cluster либо изнутри VPC, либо извне, если трафик не из public-cluster. Я открыл службы, работающие на private-cluster используя внутренний балансировщик нагрузки, поэтому у каждой службы есть собственный внутренний IP-адрес. Шлюз API использует эти внутренние IP-адреса для перенаправления входящих запросов на внутренние микросервисы.

public-cluster и private-cluster находятся в разных подсетях в одном регионе в одном VPC.

Предполагаемую архитектуру можно увидеть здесь:

.

Эта проблема

Я пытаюсь создать правила брандмауэра, которые будут блокировать весь трафик на private-cluster если это не исходит от public-cluster, следующим образом:

Если я подключусь по SSH к узлу внутри public-cluster и запускать запросы curl к службе на private-cluster (с использованием IP-адреса внутреннего балансировщика нагрузки службы) указанные выше правила брандмауэра правильно разрешают трафик. Однако, если я отправлю запросы с локального компьютера на public-cluster API Gateway, правила брандмауэра блокируют трафик. Похоже, что в этом случае сетевой тег в правиле брандмауэра игнорируется.

Я пробовал несколько вещей, чтобы правила работали (все безуспешно), например:

Вопросы

Итак, мои вопросы:

  1. Как правильно определить это правило брандмауэра, чтобы запросы перенаправлялись из шлюза API, запущенного на public-cluster разрешено через брандмауэр private-cluster?
  2. В более общем смысле, является ли это типичным архитектурным шаблоном для кластеров Kubernetes (то есть наличие общедоступного кластера, на котором запущен API-шлюз, который перенаправляет запросы на серверный не общедоступный кластер), и, если нет, есть ли лучший способ спроектировать это? (Я понимаю, что это очень субъективный вопрос, но мне интересно услышать об альтернативных подходах)

Я заставил это работать, добавив правило брандмауэра, которое разрешает порты 80/443 из public-clusterдиапазон адресов pod'а в private-clusterсетевые теги.

  1. Получить public-clustersДиапазон адресов пода:
gcloud container clusters describe public-cluster --zone europe-west2-a | grep clusterIpv4Cidr
  1. Создать правило брандмауэра (заменить --source-ranges=XX.XX.X.X/XX с диапазоном адресов модуля):
gcloud compute firewall-rules create allow-public-cluster-to-private-cluster \
    --direction=INGRESS \
    --priority=1000 \
    --network=custom-vpc \
    --action=ALLOW \
    --rules=tcp:80,tcp:443 \
    --source-ranges=XX.XX.X.X/XX \
    --target-tags=private-cluster

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

Лучший способ - применить метки к узлам общедоступного кластера, а затем открыть порт в частном кластере, разрешая только данную метку. Все брандмауэры gcp могут быть основаны на метках, а не только на IP или классах.