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

Проблемы с ограничением доступа к гибкой службе движка приложений с помощью VPC

Я пытаюсь ограничить доступ к определенной службе App Engine Flex в проекте с несколькими службами, используя правила брандмауэра VPC. Я создал сеть VPC под названием «vpc», используя автоматическое создание подсети и глобальную динамическую маршрутизацию. Затем я развернул свое приложение со следующим файлом yaml (имена немного изменены):

runtime: custom
env: flex
service: someservice
manual_scaling:
    instances: 1
resources:
    cpu: 1
    memory_gb: 4.0
    disk_size_gb: 10
beta_settings:
    cloud_sql_instances: cloud
network:
    name: vpc

Как видите, я указал сеть в файле yaml для запуска приложения в vpc. Затем я создал два правила брандмауэра в VPC, чтобы разрешить доступ только к определенным IP-адресам. Сначала я создал правило брандмауэра под названием "deny", чтобы запретить доступ к сети vpc для всех диапазонов IP-адресов:

gcloud compute firewall-rules create deny \
    --network vpc \
    --action deny \
    --direction ingress \
    --rules tcp \
    --source-ranges 0.0.0.0/0 \
    --priority 5000

Наконец, я создал еще одно правило под названием «разрешить», чтобы разрешить использование одного IP-адреса (например, 192.00.00.11):

gcloud compute firewall-rules create allow \
    --network vpc \
    --action allow \
    --direction ingress \
    --rules tcp \
    --source-ranges 192.00.00.11 \
    --priority 1000

Однако после выполнения вышеизложенного я все еще могу получить доступ к службе движка приложений практически с любого протестированного мной IP-адреса (использовал данные своего телефона, а также попросил друзей проверить работоспособность). Что я делаю не так? Любая помощь приветствуется!

Примечание: аналогичная проблема: https://stackoverflow.com/questions/49296666/google-app-engine-firewall-restrict-access-to-all-services-but-the-default-one

в соответствии с документами исходные диапазоны должны быть в формате CIDR или подразумевается 0.0.0.0 - ваш исходный адрес не в нотации CIDR - исходные диапазоны 192.00.00.11 не являются диапазоном

a.b.c.d / 32

или a.b.c.d / 255.255.255.255 - в зависимости от того, как glcoud реализует это

только что посмотрел, это реализовано так --source-range 192.0.0.11/32

Я подозреваю, что уже существует более разрешающее правило брандмауэра или правило с более высоким приоритетом, чем «запретить все», созданное вами вручную. По умолчанию все созданные правила брандмауэра имеют приоритет 1000, приоритет правила брандмауэра является целым числом от 0 до 65535 включительно. Меньшие целые числа указывают на более высокий приоритет. Если вы не укажете приоритет при создании правила, ему будет назначен приоритет 1000. Приоритет 1000 является более высоким приоритетом, чем ваше правило «запретить все» с приоритетом 5000.

У вас есть как минимум пара вариантов для проверки:

  • Один из них - установить для вашего правила «запретить все» более высокий приоритет (например, 900), а затем повторно протестировать соединения, увеличивая приоритет «запретить все» по мере необходимости. Это легко выполнимый, но не лучший вариант.

  • Второй: в консоли Cloud Platform выберите сеть VPC -> Сети VPC. Щелкните / выберите имя VPC, с которым вы работаете, затем выберите вкладку «Правила межсетевого экрана». В нем будут перечислены все правила брандмауэра, активные в настоящее время для этого VPC. Просмотрите список и найдите правило с более высоким приоритетом (меньшее целочисленное значение), которое является более разрешительным (возможно, даже разрешает все), чем ваше правило «запретить все». Затем удалите это правило или измените приоритет на более низкий, чем у вашего правила «запретить все».