1. Введение
Балансировка нагрузки Google Cloud развертывается на границе сети Google в точках присутствия Google (POP) по всему миру. Пользовательский трафик, направляемый на балансировщик нагрузки TCP-прокси, поступает на POP, ближайший к пользователю, а затем балансируется через глобальную сеть Google на ближайший бэкэнд, имеющий достаточную доступную мощность.
Cloud Armor — это распределенная система обнаружения отказов в обслуживании и брандмауэра веб-приложений (WAF) Google. Cloud Armor тесно связан с балансировщиком нагрузки прокси-сервера Google Cloud TCP и позволяет опрашивать входящий трафик на наличие нежелательных запросов. Функция ограничения скорости этой службы позволяет вам ограничивать трафик на серверные ресурсы в зависимости от объема запроса и предотвращает потребление ресурсов нежелательным трафиком в вашей сети виртуального частного облака (VPC).
Балансировщики нагрузки прокси-сервера Google Cloud TCP/SSL позволяют проксировать трафик типа TCP/SSL между вашими серверными службами.
В этой лабораторной работе вы создадите прокси-балансировщик нагрузки TCP/SSL с внутренней службой и используете Cloud Armor, чтобы ограничить доступ к балансировщику нагрузки только определенному набору пользовательских клиентов.
Что вы узнаете
- Как создать балансировщик нагрузки прокси-сервера TCP/SSL
- Как создать политику безопасности Cloud Armor
- Как создать правило списка запрещенных IP-адресов для балансировщика нагрузки прокси-сервера TCP/SSL в Cloud Armor
- Как создать правило ограничения скорости для балансировщика нагрузки TCP-прокси в Cloud Armor
- Как добавить политику безопасности к внутренней службе балансировки нагрузки TCP/SSL
Что вам понадобится
- Базовые знания Google Compute Engine ( codelab ).
- Базовые знания сетевых технологий и TCP/IP.
- Базовые знания командной строки Unix/Linux.
- Полезно пройти экскурсию по сетям в GCP с помощью Networking в Google Cloud.
2. Требования
Самостоятельная настройка среды
- Войдите в Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .
Примечание. Вы можете легко получить доступ к Cloud Console, запомнив ее URL-адрес — console.cloud.google.com.
Запомните идентификатор проекта — уникальное имя для всех проектов Google Cloud (имя, указанное выше, уже занято и не подойдет вам, извините!). Позже в этой лаборатории он будет называться PROJECT_ID.
Примечание. Если вы используете учетную запись Gmail, вы можете оставить для местоположения по умолчанию значение «Нет организации». Если вы используете учетную запись Google Workspace, выберите местоположение, подходящее для вашей организации.
- Далее вам необходимо включить биллинг в Cloud Console, чтобы использовать ресурсы Google Cloud.
Прохождение этой лаборатории кода не должно стоить много, если вообще стоит. Обязательно следуйте всем инструкциям в разделе «Очистка», в которых рассказывается, как отключить ресурсы, чтобы вам не приходилось нести расходы, выходящие за рамки этого руководства. Новые пользователи Google Cloud имеют право на участие в программе бесплатной пробной версии стоимостью 300 долларов США .
Запустить Cloud Shell
Хотя Google Cloud можно управлять удаленно с вашего ноутбука, в этой лаборатории вы будете использовать Google Cloud Shell , среду командной строки, работающую в облаке.
В консоли GCP щелкните значок Cloud Shell на верхней правой панели инструментов:
Подготовка и подключение к среде займет всего несколько минут. Когда все будет готово, вы должны увидеть что-то вроде этого:
Эта виртуальная машина оснащена всеми необходимыми инструментами разработки. Он предлагает постоянный домашний каталог объемом 5 ГБ и работает в Google Cloud, что значительно повышает производительность сети и аутентификацию. Всю работу в этой лабораторной работе можно выполнять с помощью простого браузера.
Прежде чем начать
В Cloud Shell убедитесь, что идентификатор вашего проекта настроен.
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] PROJECT_ID=[YOUR-PROJECT-NAME] echo $PROJECT_ID
Включить API
Включите все необходимые сервисы
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. Создайте серверные службы
Создайте 2 экземпляра следующим образом: создайте экземпляр 1-b1 в зоне us-central1-b.
gcloud compute instances create vm-1-b1 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b1 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
Создайте экземпляр 1-b2 в зоне us-central1-b.
gcloud compute instances create vm-1-b2 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b2 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
Создайте группу экземпляров vm-ig1.
gcloud compute instance-groups unmanaged create vm-ig1 --zone us-central1-b
Создайте именованный порт для группы экземпляров. Для этой лабораторной работы мы будем использовать порт 110.
gcloud compute instance-groups set-named-ports vm-ig1 \ --named-ports tcp 110:110 --zone us-central1-b
Добавьте экземпляры в группу экземпляров
gcloud compute instance-groups unmanaged add-instances vm-ig1 \ --instances vm-1-b1,vm-1-b2 --zone us-central1-b
4. Настройка балансировщика нагрузки
Далее мы создадим проверку работоспособности.
gcloud compute health-checks create tcp my-tcp-health-check --port 110
Создайте серверную службу
gcloud compute backend-services create my-tcp-lb --global-health-checks --global \ --protocol TCP --health-checks my-tcp-health-check --timeout 5m --port-name tcp110
Добавьте группу экземпляров во внутреннюю службу.
gcloud compute backend-services add-backend my-tcp-lb --global --instance-group \ vm-ig1 --instance-group-zone us-central1-b --balancing-mode UTILIZATION \ --max-utilization 0.8
Настройте целевой TCP-прокси
gcloud compute target-tcp-proxies create my-tcp-lb-target-proxy --backend-service \ my-tcp-lb --proxy-header NONE
Зарезервируйте глобальные статические адреса IPv4.
Вы будете использовать этот IP-адрес для доступа к службе балансировки нагрузки.
gcloud compute addresses create tcp-lb-static-ipv4 --ip-version=IPV4 --global
Настройте глобальные правила переадресации для IP-адреса LB.
gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
--global --target-tcp-proxy my-tcp-lb-target-proxy --address LB_STATIC_IPV4 \ --ports 110
5. Создание правила межсетевого экрана для балансировщика нагрузки TCP-прокси.
gcloud compute firewall-rules create allow-tcplb-and-health \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --target-tags tcp-lb \ --allow tcp:110
После создания балансировщика нагрузки протестируйте его с помощью следующей команды
Curl LB_IP:110
Затем создайте виртуальную машину для проверки отказа в доступе к LB.
Вам следует создать 2 экземпляра, каждый с общедоступным IP-адресом и именами test-server1 и test-server2.
6. Создайте политику безопасности в Cloud Armor.
В этом разделе вы создадите внутреннюю политику безопасности и 2 правила в политике в Cloud Armor.
Первое правило запретит ограниченному набору IP-адресов доступ к балансировщику нагрузки TCP, установив политику безопасности, запрещающую определенные IP-адреса, а второе правило будет выполнять ограничение скорости.
- В Cloud Shell (инструкции по использованию Cloud Shell см. в разделе «Запуск Cloud Shell» в разделе «Настройка и требования») создайте политику безопасности серверной службы под названиемrate-limit-and-deny-tcp следующим образом.
gcloud compute security-policies create rate-limit-and-deny-tcp \
--description "policy for tcp proxy rate limiting and IP deny"
Добавьте правила в политику безопасности
Затем добавьте правило списка запретов в политику Cloud Armor «rate-limit-and-deny-tcp».
gcloud compute security-policies rules create 1000 --action deny --security-policy \ rate-limit-and-deny-tcp --description "deny test-server1" --src-ip-ranges \ "enter-test-server-1ip-here"
Добавьте правило ограничения скорости в политику безопасности Cloud Armor «rate-limit-and-deny-tcp».
gcloud compute security-policies rules create 3000 \ --security-policy=rate-limit-and-deny-tcp \ --expression="true" --action=rate-based-ban --rate-limit-threshold-count=5 \ --rate-limit-threshold-interval-sec=60 --ban-duration-sec=300 \ --conform-action=allow --exceed-action=deny-404 --enforce-on-key=IP
Прикрепите политику к внутренней службе TCP-прокси:
Выполните следующую команду, чтобы убедиться, что политика безопасности прикреплена к внутренней службе TCP-прокси.
gcloud compute backend-services update my-tcp-lb --security-policy \ rate-limit-and-deny-tcp
Включить ведение журнала в TCP-прокси-балансировщике нагрузки
gcloud beta compute backend-services update my-tcp-lb \ --enable-logging --logging-sample-rate=1
7. Подтвердите правило списка запрещенных
Подтвердите правило списка запретов, войдя на тестовый сервер, IP-адрес которого был указан в правиле списка запретов, и выполните следующую команду
Curl LB_IP:110
Немедленные запросы могут дать ответ от LB, но подождите, пока запрос на завивку не будет отклонен или удален, а затем просмотрите журналы в Cloud Logging, чтобы проверить запись журнала для срабатывания правила запрета IP-адресов.
Перейдите в раздел «Облачное ведение журнала» и в разделе «Ресурсы» выберите тип ресурса «tcp_ssl_proxy_rule» и установите цель серверной части как «my-tcp-lb».
Имея ресурсы, определенные для фильтрации, мы можем убедиться, что правило запрета IP-адреса действует, используя значение PRIORITY, равное 1000 в записи журнала, и настроенное действие «DENY» действует, поскольку оба были проинструктированы из правила запрета и IP-адреса. отказано, как показано ниже
8. Подтвердить правило ограничения скорости
Убедитесь, что правило ограничения скорости действует, отправив множество запросов за короткий промежуток времени, превышающих определенный порог (5 запросов в минуту).
Как только это будет сделано, щелкните просмотр журналов в службе облачной защиты, и вы перейдете к облачной регистрации, где вы сможете фильтровать журналы с помощью балансировщика нагрузки, чтобы просматривать журналы облачной защиты по мере их поступления.
Запись, ограничивающая скорость, должна выглядеть так, как показано на снимке экрана ниже. Мы можем убедиться в том, что правило ограничения скорости действует, исходя из значения ПРИОРИТЕТА , равного 3000, в записи журнала, а также из настроенного действия: действие «БАН НА ОСНОВЕ СТАВКИ» действует в соответствии с инструкциями правила ограничения скорости.
9. Очистка окружающей среды
Обязательно очистите созданную инфраструктуру, чтобы избежать эксплуатационных расходов на неиспользуемую инфраструктуру.
Самый быстрый способ — удалить весь проект в GCP, чтобы убедиться, что не осталось ни одного висящего ресурса без присмотра. Однако удалите отдельные ресурсы с помощью следующих команд.
Балансировщик нагрузки TCP-прокси
gcloud compute target-tcp-proxies delete my-tcp-lb
Группа экземпляров
gcloud compute instance-groups unmanaged delete vm-ig1
Созданы 2 тестовых экземпляра виртуальной машины.
gcloud compute instances delete Instance_name --zone=instance_zone
Серверная служба
gcloud compute backend-services delete BACKEND_SERVICE_NAME
Правила Cloud Armor в рамках политики
gcloud compute security-policies rules delete 1000 \ --security-policy=rate-limit-and-deny-tcp && gcloud compute security-policies rules delete 3000 \ --security-policy=rate-limit-and-deny-tcp
Политика безопасности облачной брони
gcloud compute security-policies delete rate-limit-and-deny-tcp