Как использовать Google Cloud Armor для внесения в белый список только нескольких IP-адресов на GKE?

мы пытаемся заблокировать весь некластерный трафик, за исключением нескольких внешних IP-адресов, на основе этой Cloud Armor пройти.

Кластер GKE распознает правила, но по-прежнему блокирует разрешенный IP-адрес. Вот следующие шаги:

1) Создайте политику + правила

gcloud beta compute security-policies create allow-team-only \
    --description "Cloud Armor deny non-team IPs"


gcloud beta compute security-policies rules create 1000 \
    --security-policy allow-team-only \
    --description "Deny traffic from 0.0.0.0/0." \
    --src-ip-ranges "0.0.0.0/0" \
    --action "deny-404"


gcloud beta compute security-policies rules create 999 \
    --security-policy allow-team-only \
    --description "Allow traffic from <IP ADDRESS>." \
    --src-ip-ranges "<IP ADDRESS>/32" \
    --action "allow"

2) Примените правила к нашим сервисам, которые находятся на порту 8080

metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {"8080":"allow-team-only"}}'

Что я упускаю из виду?

Спасибо!


google-cloud-platform google-kubernetes-engine google-cloud-armor google-cloud-networking
person Mike    schedule 08.10.2018    source источник

Ответы (2)


arrow_upward
3
arrow_downward

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

1) Вы создали с номером 1000, и, поскольку он все отрицает, любое дальнейшее добавление правил с номером с 1000+ работать не будет. Поскольку весь трафик будет соответствовать 0.0.0.0/0 и 1000+, правила не будут проверяться. 2) Согласно GCP, вы могли использовать правило по умолчанию и изменить действие на отказ (закрытие при отказе).

Согласно документации GCP по политикам безопасности Cloud Armor

Каждая политика безопасности Cloud Armor содержит правило по умолчанию, которое выполняется, если не соответствует ни одно из правил с более высоким приоритетом или если в политике нет других правил. Правилу по умолчанию автоматически назначается приоритет 2147483647 (макс. Int32), и он всегда присутствует в политике безопасности Cloud Armor. Правило по умолчанию нельзя удалить, но его можно изменить. Действие по умолчанию для правила по умолчанию - разрешить (открытие при отказе), но вы можете изменить действие на запретить (закрытие при отказе).

Я также заметил, что ваш сценарий очень похож на первый вариант использования "Вариант использования 1: Ограничение доступа к балансировщику нагрузки GCP HTTP (S) ", описанное в том же документе, которым вы поделились.

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

1) Создайте политику безопасности Cloud Armor.
2) В политике безопасности Cloud Armor добавьте правило, которое заносится в белый список в качестве первого правила. У этого правила есть описание «разрешить».
3) Измените правило по умолчанию в политике с разрешающего правила на запрещающее. Правило по умолчанию управляет трафиком, который не соответствует ни одному из предыдущих правил. Это последнее правило политики. Изменение правила с разрешения на запрет блокирует весь трафик, который не находится в белом списке.
4) Свяжите эту политику с серверной службой балансировщика нагрузки HTTP (S).

person Nur    schedule 09.10.2018
comment
Могу ли я не применять это ко всем балансировщикам нагрузки в проекте? Нет никакого смысла в том, что я не могу применить его ко всей организации или проекту. Как невероятно утомительно и обременительно указывать целевые объекты, которые постоянно создаются и уничтожаются динамически при тестировании GKE и разработчиками в промежуточном режиме. - person Nathan McKaskle; 12.05.2020
comment
Я добавил команды для выполнения вышеуказанных шагов к этому ответу здесь: stackoverflow.com/a/62675760/2609980 - person Erwin Rooijakkers; 01.07.2020

arrow_upward
1
arrow_downward

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

person Mike    schedule 08.10.2018