Политика брандмауэра глобальной сети с тегами,Политика брандмауэра глобальной сети с тегами

1. Введение

Политики сетевого брандмауэра

Межсетевые экраны являются основными строительными блоками безопасной облачной среды. Ранее мы ввели политики брандмауэра на уровне организации и папки, оставив брандмауэры VPC без изменений. В этой версии мы собираемся расширить структуру политики брандмауэра до уровня VPC и внести несколько улучшений в текущую поддержку политики брандмауэра, чтобы обеспечить унифицированную поддержку брандмауэра во всей иерархии ресурсов Google Cloud и единообразный интерфейс управления политикой брандмауэра для пользователей. управление безопасным, гибким и масштабируемым способом.

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

Совместное использование политики межсетевого экрана в разных сетях и интеграция с тегами, управляемыми IAM, значительно упрощает настройку и управление межсетевыми экранами.

С появлением политики сетевого брандмауэра политики брандмауэра Google Cloud теперь состоят из следующих компонентов:

1. Иерархическая политика брандмауэра
2. Правила брандмауэра VPC
3. Политика сетевого брандмауэра ( глобальная и региональная )

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

Наконец, у нас также есть подразумеваемые правила брандмауэра , которые есть в каждой сети VPC:

• Выходное правило, действие которого разрешено, пункт назначения — 0.0.0.0/0.
• Входное правило, действие которого запрещено, источник — 0.0.0.0/0.

По умолчанию последовательность применения показана на следующей диаграмме:

Обратите внимание, что порядок применения правил брандмауэра VPC и политики брандмауэра глобальной сети можно поменять местами. Клиенты могут указать порядок принудительного исполнения в любое время с помощью команды gcloud .

Теги

Новые теги, интегрированные в правила политики сетевого брандмауэра, представляют собой ресурсы пары «ключ-значение», определенные на уровне организации иерархии ресурсов Google Cloud. Такой тег содержит элемент управления доступом IAM, как следует из названия, который определяет, кто и что может делать с тегом. Разрешения IAM, например, позволяют указать, какие участники могут присваивать значения тегам, а какие участники могут прикреплять теги к ресурсам. После применения тега к ресурсу правила сетевого брандмауэра могут использовать его для разрешения и запрета трафика.

Теги соответствуют модели ресурсов наследования Google Cloud, то есть теги и их значения передаются по иерархии от их родителей. В результате теги могут создаваться в одном месте, а затем использоваться другими папками и проектами по всей иерархии ресурсов. Посетите эту страницу для получения более подробной информации о тегах и ограничении доступа.

Теги не следует путать с сетевыми тегами , последние представляют собой строки, которые можно добавлять к экземплярам Compute Engine; они связаны с экземпляром и исчезают, когда экземпляр выводится из эксплуатации. Правила брандмауэра VPC могут включать сетевые теги, но, поскольку они не считаются облачными ресурсами, на них не распространяется контроль доступа IAM.

Обратите внимание, что теги и теги, управляемые IAM, в этом документе используются как взаимозаменяемые слова.

Что ты построишь

Эта кодовая лаборатория состоит из двух частей: первая демонстрирует политики сетевого межсетевого экрана и теги с использованием одной сети VPC, а вторая показывает, как использовать теги в одноранговых сетях VPC, как показано на схеме ниже. Таким образом, для этой лаборатории кода требуется один проект и возможность создания нескольких сетей VPC.

Что вы узнаете

• Как создать политику сетевого брандмауэра
• Как создавать и использовать теги с политикой сетевого брандмауэра
• Как использовать теги через пиринг сети VPC

Что вам понадобится

• Проект Google Cloud
• Знание развертывания экземпляров и настройки сетевых компонентов.
• Знание конфигурации брандмауэра VPC

2. Прежде чем начать

Создать/обновить переменные

В этой лаборатории кода используются переменные $variables для облегчения реализации конфигурации gcloud в Cloud Shell.

Внутри Cloud Shell выполните следующие действия:

Примечание . Идентификатор организации можно получить с помощью Cloud Console или gcloud projects get-ancestors [project-id] .

gcloud config set project [project-id]
export project_id=`gcloud config list --format="value(core.project)"`
export org_id=[org]
export region=us-central1
export zone=us-central1-a
export prefix=fwpolicy

Примечание . Если вы раньше работали с Google Cloud и уже установили gcloud , обновили его и прошли аутентификацию в своем проекте, не стесняйтесь использовать для этой лабораторной работы свой локальный компьютер вместо Cloud Shell. Если не указано иное, все команды gcloud следует запускать с компьютера, на котором уже установлен*** gcloud *** *** или Cloud Shell.***

3. Создайте сеть и подсеть VPC.

Примечание . Убедитесь, что API Compute Engine включен. Если при выполнении приведенных ниже команд вы получили сообщение об ошибке или не уверены, запустите gcloud services enable compute.googleapis.com и повторите попытку.

Сеть VPC

Создайте fwpolicy-vpc1:

gcloud compute networks create $prefix-vpc1 --subnet-mode=custom 

Подсети

Создайте соответствующие подсети в выбранном регионе:

gcloud compute networks subnets create $prefix-vpc1-subnet \
   --range=10.0.0.0/24 --network=$prefix-vpc1 --region=$region

Облачный NAT

Создайте облачные маршрутизаторы и шлюзы Cloud NAT для fwpolicy-pc1 :

gcloud compute routers create $prefix-vpc1-cr \
  --region=$region --network=$prefix-vpc1

gcloud compute routers nats create $prefix-vpc1-cloudnat \
   --router=$prefix-vpc1-cr --router-region=$region \
   --auto-allocate-nat-external-ips \
   --nat-all-subnet-ip-ranges

4. Создайте экземпляры

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

Создайте правило брандмауэра, которое разрешает входящий SSH-трафик из диапазонов IAP, если оно еще не было определено как часть настройки IAP:

gcloud compute firewall-rules create allow-ssh-ingress-from-iap-vpc1 \
  --direction=INGRESS \
  --action=allow \
  --network=$prefix-vpc1 \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20

Создайте экземпляры клиента и веб-сервера fwpolicy-vpc1 :

gcloud compute instances create $prefix-vpc1-www \
   --subnet=$prefix-vpc1-subnet --no-address --zone $zone \
   --metadata startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
# Read VM network configuration:
md_vm="http://169.254.169.254/computeMetadata/v1/instance/"
vm_hostname="$(curl $md_vm/name -H "Metadata-Flavor:Google" )"
filter="{print \$NF}"
vm_network="$(curl $md_vm/network-interfaces/0/network \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
vm_zone="$(curl $md_vm/zone \
-H "Metadata-Flavor:Google" | awk -F/ "${filter}")"
# Apache configuration:
echo "Page on $vm_hostname in network $vm_network zone $vm_zone" | \
tee /var/www/html/index.html
systemctl restart apache2'

gcloud compute instances create $prefix-vpc1-client \
    --subnet=$prefix-vpc1-subnet --no-address --zone $zone

Поскольку не определены правила брандмауэра VPC (кроме правила разрешения SSH, которое должно было быть создано при настройке IAP, как указано в начале этого раздела), а по умолчанию весь входящий трафик запрещен, экземпляры клиентов не смогут получить доступ соответствующие веб-серверы. Чтобы убедиться, что время ожидания запроса истекло, откройте новое окно, инициируйте сеанс SSH с экземпляром fwpolicy-vpc1-client и попытайтесь свернуть веб-сервер:

user@fwpolicy-vpc1-client$ curl fwpolicy-vpc1-www --connect-timeout 2

Ожидаемый результат:

curl: (28) Connection timed out after 2001 milliseconds

При необходимости убедитесь, что для fwpolicy-vpc1 не определены правила брандмауэра VPC через Cloud Shell:

gcloud compute firewall-rules list --filter="network:$prefix-vpc1"

5. Политика брандмауэра глобальной сети

Создайте политику брандмауэра глобальной сети:

gcloud compute network-firewall-policies create \
   $prefix-example --description \
   "firewall-policy-description" --global

Добавьте правило, разрешающее веб-трафик:

gcloud compute network-firewall-policies rules create 500 \
    --action allow \
    --description "allow-web" \
    --layer4-configs tcp:80,tcp:443 \
    --firewall-policy $prefix-example \
    --src-ip-ranges 10.0.0.0/16 \
    --global-firewall-policy --enable-logging

Опишите политику сетевого брандмауэра и убедитесь, что правило было успешно added :

gcloud compute network-firewall-policies describe \
    $prefix-example --global

Ожидаемый результат (прокрутите до начала вывода; обратите внимание, что также отображаются неявные правила):

creationTimestamp: '2022-09-23T12:46:53.677-07:00'
description: "firewall-policy-description"
fingerprint: Np1Rup09Amc=
id: '7021772628738421698'
kind: compute#firewallPolicy
name: fwpolicy-example
ruleTupleCount: 13
rules:
- action: allow
  description: allow-web
  direction: INGRESS
  disabled: false
  enableLogging: true
  kind: compute#firewallPolicyRule
  match:
    layer4Configs:
    - ipProtocol: tcp
      ports:
      - '80'
    - ipProtocol: tcp
      ports:
      - '443'
    srcIpRanges:
    - 10.0.0.0/16
  priority: 500
  ruleTupleCount: 5
...

Свяжите политику сетевого брандмауэра с fwpolicy-vpc1 :

gcloud compute network-firewall-policies associations create \
     --firewall-policy $prefix-example \
     --network $prefix-vpc1 \
     --name $prefix-vpc1-association \
     --global-firewall-policy

Убедитесь, что оно было успешно применено к сети fwpolicy-vpc1 :

gcloud compute networks get-effective-firewalls $prefix-vpc1

Ожидаемый результат (обратите внимание, что если приоритет имеют иерархические политики брандмауэра, соответствующие правила будут отображаться вверху):

TYPE                     FIREWALL_POLICY_NAME     PRIORITY    ACTION     DIRECTION  IP_RANGES
network-firewall-policy  fwpolicy-example      500         ALLOW      INGRESS    10.0.0.0/16
network-firewall-policy  fwpolicy-example      2147483645  GOTO_NEXT  INGRESS    ::/0
network-firewall-policy  fwpolicy-example      2147483647  GOTO_NEXT  INGRESS    0.0.0.0/0
network-firewall-policy  fwpolicy-example      2147483644  GOTO_NEXT  EGRESS     ::/0
network-firewall-policy  fwpolicy-example      2147483646  GOTO_NEXT  EGRESS     0.0.0.0/0

Убедитесь, что оно также было успешно применено к веб-серверу fwpolicy-vpc1 :

gcloud compute instances network-interfaces \
   get-effective-firewalls $prefix-vpc1-www --zone $zone

Ожидаемый результат аналогичен предыдущей команде (эффективные межсетевые экраны fwpolicy-vpc1 ):

TYPE                     FIREWALL_POLICY_NAME     PRIORITY    ACTION     DIRECTION  IP_RANGES
network-firewall-policy  fwpolicy-example      500         ALLOW      INGRESS    10.0.0.0/16
network-firewall-policy  fwpolicy-example      2147483645  GOTO_NEXT  INGRESS    ::/0
network-firewall-policy  fwpolicy-example      2147483647  GOTO_NEXT  INGRESS    0.0.0.0/0
network-firewall-policy  fwpolicy-example      2147483644  GOTO_NEXT  EGRESS     ::/0
network-firewall-policy  fwpolicy-example      2147483646  GOTO_NEXT  EGRESS     0.0.0.0/0

Вернитесь к сеансу SSH vpc1-client и повторите попытку скручивания (обратите внимание, что в приведенной ниже команде предполагается, что в качестве префикса использовалось fwpolicy ; если вместо этого использовалось другое имя, измените команду curl соответствующим образом):

user@vpc1-client$ curl fwpolicy-vpc1-www --connect-timeout 2
Page on vpc1-www in network vpc1 zone us-central1-a

В Cloud Shell убедитесь, что политика сетевого брандмауэра применяется к fwpolicy-vpc1 :

gcloud compute network-firewall-policies describe \
   $prefix-example --global

Ожидаемый результат (прокрутите до начала вывода):

---
associations:
- attachmentTarget: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/fwpolicy-vpc1
  name: fwpolicy-vpc1-association
...

6. Теги, управляемые IAM

Тег — это пара ключ-значение, которую можно прикрепить к организации, папке или проекту. Дополнительные сведения см. в разделе Создание тегов и управление ими , а также необходимые разрешения .

Роль tagAdmin позволяет создавать новые теги, обновлять и удалять существующие теги. Эту роль может предоставить администратор организации. В Cloud Shell обновите политику IAM, чтобы добавить своему пользователю роль tagAdmin . Используйте справочную страницу разрешений , чтобы узнать, какие разрешения включены в каждую предопределенную роль.

gcloud organizations add-iam-policy-binding $org_id \
  --member user:[[e-mail]] --role roles/resourcemanager.tagAdmin

Запустите команду ниже, чтобы проверить, какие пользователи имеют роль resourcesmanager.tagAdmin:

gcloud organizations get-iam-policy $org_id --flatten=bindings \
  --filter=bindings.role:roles/resourcemanager.tagAdmin

Создайте новый ключ тега:

gcloud resource-manager tags keys create tags-vpc1 \
   --parent organizations/$org_id \
   --purpose GCE_FIREWALL \
   --purpose-data network=$project_id/$prefix-vpc1

Ожидаемый результат:

Waiting for TagKey [tags-vpc1] to be created...done.                                                                                                                
createTime: '2022-09-23T20:49:01.162228Z'
etag: PwvmFuHO4wK1y6c5Ut2n5w==
name: tagKeys/622132302133
namespacedName: ORGANIZATION_ID/tags-vpc1
parent: organizations/ORGANIZATION_ID
purpose: GCE_FIREWALL
purposeData:
  network: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/6749205358365096383
shortName: tags-vpc1
updateTime: '2022-09-23T20:49:03.873776Z'

Примечание . Обязательно убедитесь, что GCE_FIREWALL отображается, как указано выше, в противном случае функциональность тегов для брандмауэров не будет работать должным образом.

Создайте новые значения тегов:

gcloud resource-manager tags values create web-servers \
   --parent=$org_id/tags-vpc1

gcloud resource-manager tags values create web-clients \
   --parent=$org_id/tags-vpc1

Убедитесь, что значения тегов были успешно созданы:

gcloud resource-manager tags values list \
   --parent=$org_id/tags-vpc1

Ожидаемый результат:

NAME                    SHORT_NAME   DESCRIPTION
tagValues/349564376683  web-servers
tagValues/780363571446  web-clients

В Cloud Shell опишите существующее правило политики сетевого брандмауэра, чтобы убедиться, что теги не используются:

gcloud compute network-firewall-policies rules describe 500 \
    --firewall-policy $prefix-example \
    --global-firewall-policy

Ожидаемый результат:

---
action: allow
description: allow-web
direction: INGRESS
disabled: false
enableLogging: true
kind: compute#firewallPolicyRule
match:
  layer4Configs:
  - ipProtocol: tcp
    ports:
    - '80'
  - ipProtocol: tcp
    ports:
    - '443'
  srcIpRanges:
  - 10.0.0.0/16
priority: 500
ruleTupleCount: 5

В Cloud Shell обновите правило, чтобы разрешить трафик только из ключа тега vpc1-tags/web-clients , и установите правило на экземплярах с ключом тега vpc1-tags/web-servers .

gcloud compute network-firewall-policies rules update 500 \
    --firewall-policy $prefix-example \
    --src-secure-tags $org_id/tags-vpc1/web-clients \
    --target-secure-tags $org_id/tags-vpc1/web-servers \
    --global-firewall-policy

В Cloud Shell опишите существующее правило политики сетевого брандмауэра, чтобы убедиться, что теги были успешно применены и отображаются как ЭФФЕКТИВНЫЕ :

gcloud compute network-firewall-policies rules describe 500 \
    --firewall-policy $prefix-example \
    --global-firewall-policy

Ожидаемый результат:

---
action: allow
description: allow-web
direction: INGRESS
disabled: false
enableLogging: false
kind: compute#firewallPolicyRule
match:
  layer4Configs:
  - ipProtocol: tcp
    ports:
    - '80'
  - ipProtocol: tcp
    ports:
    - '443'
  srcIpRanges:
  - 10.0.0.0/16
  srcSecureTags:
  - name: tagValues/479619031616
    state: EFFECTIVE
priority: 500
ruleTupleCount: 7
targetSecureTags:
- name: tagValues/230424970229
  state: EFFECTIVE

В Cloud Shell давайте проверим, что правило было применено к vpc1 :

gcloud compute networks get-effective-firewalls $prefix-vpc1

Ожидаемый результат:

network-firewall-policy  fwpolicy-example      500         ALLOW      INGRESS    10.0.0.0/16
network-firewall-policy  fwpolicy-example      2147483645  GOTO_NEXT  INGRESS    ::/0
network-firewall-policy  fwpolicy-example      2147483647  GOTO_NEXT  INGRESS    0.0.0.0/0
network-firewall-policy  fwpolicy-example      2147483644  GOTO_NEXT  EGRESS     ::/0
network-firewall-policy  fwpolicy-example      2147483646  GOTO_NEXT  EGRESS     0.0.0.0/0

Убедитесь, что, хотя политика сетевого брандмауэра по-прежнему связана с сетью VPC, правило, разрешающее веб-трафик, больше не применяется к веб-серверу, поскольку тег не был добавлен к экземплярам:

gcloud compute instances network-interfaces \
   get-effective-firewalls $prefix-vpc1-www --zone $zone

Ожидаемый результат (обратите внимание, что правило брандмауэра с приоритетом 500 не отображается):

network-firewall-policy  fwpolicy-example      2147483645  GOTO_NEXT  INGRESS    ::/0
network-firewall-policy  fwpolicy-example      2147483647  GOTO_NEXT  INGRESS    0.0.0.0/0
network-firewall-policy  fwpolicy-example      2147483644  GOTO_NEXT  EGRESS     ::/0
network-firewall-policy  fwpolicy-example      2147483646  GOTO_NEXT  EGRESS     0.0.0.0/0

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

gcloud resource-manager tags keys add-iam-policy-binding \
  $org_id/tags-vpc1 \
  --member user:[email] --role roles/resourcemanager.tagUser

gcloud projects add-iam-policy-binding $project_id \
  --member user:[email] --role roles/resourcemanager.tagUser

Убедитесь, что роль успешно добавлена:

gcloud resource-manager tags keys get-iam-policy $org_id/tags-vpc1

gcloud projects get-iam-policy $project_id --flatten=bindings \
   --filter=bindings.role:roles/resourcemanager.tagUser

Ожидаемый результат:

bindings:
- members:
  - user:[user]
  role: roles/resourcemanager.tagUser
...

Примените тег к экземпляру fwpolicy-vpc1-www :

gcloud resource-manager tags bindings create \
  --location $zone \
  --tag-value $org_id/tags-vpc1/web-servers \
  --parent \
//compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-vpc1-www

Ожидаемый результат:

Waiting for TagBinding for parent [//compute.googleapis.com/projects/PROJECT_ID/zones/us-central1-a/instances/38369703403698502] and tag value [tagValues/34
9564376683] to be created with [operations/rctb.us-central1-a.6144808968019372877]...done.                                                                            
done: true
metadata:
  '@type': type.googleapis.com/google.cloud.resourcemanager.v3.CreateTagBindingMetadata
name: operations/rctb.us-central1-a.6144808968019372877
response:
  '@type': type.googleapis.com/google.cloud.resourcemanager.v3.TagBinding
  name: tagBindings/%2F%2Fcompute.googleapis.com%2Fprojects%2FPROJECT_NUMBER%2Fzones%2Fus-central1-a%2Finstances%2F38369703403698502/tagValues/349564376683
  parent: //compute.googleapis.com/projects/PROJECT_NUMBER/zones/us-central1-a/instances/38369703403698502
  tagValue: tagValues/349564376683

Проверьте привязки:

gcloud resource-manager tags bindings list --location $zone --effective --parent //compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-vpc1-www 

Ожидаемый результат:

namespacedTagKey: ORGANIZATION_ID/tags-vpc1
namespacedTagValue: ORGANIZATION_ID/tags-vpc1/web-servers
tagKey: tagKeys/622132302133
tagValue: tagValues/349564376683

Еще раз проверьте действующие правила брандмауэра:

gcloud compute instances network-interfaces \
   get-effective-firewalls $prefix-vpc1-www --zone $zone

Ожидаемый результат:

network-firewall-policy  fwpolicy-example      490         ALLOW      INGRESS    10.0.0.0/16
network-firewall-policy  fwpolicy-example      2147483645  GOTO_NEXT  INGRESS    ::/0
network-firewall-policy  fwpolicy-example      2147483647  GOTO_NEXT  INGRESS    0.0.0.0/0
network-firewall-policy  fwpolicy-example      2147483644  GOTO_NEXT  EGRESS     ::/0
network-firewall-policy  fwpolicy-example      2147483646  GOTO_NEXT  EGRESS     0.0.0.0/0

Вернитесь на вкладку сеанса SSH fwpolicy-vpc1-client и попробуйте завить:

user@fwpolicy-vpc1-client$ curl fwpolicy-vpc1-www --connect-timeout 2

Удалось ли вам подключиться?

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

Чтобы убедиться в этом, обновите правило, удалив исходные критерии CIDR через Cloud Shell.

gcloud compute network-firewall-policies rules update 500 \
    --firewall-policy $prefix-example \
    --src-ip-ranges "" \
    --global-firewall-policy

gcloud compute network-firewall-policies rules describe 500 \
    --firewall-policy $prefix-example \
    --global-firewall-policy

action: allow
description: allow-web
direction: INGRESS
disabled: false
enableLogging: false
kind: compute#firewallPolicyRule
match:
  layer4Configs:
  - ipProtocol: tcp
    ports:
    - '80'
  - ipProtocol: tcp
    ports:
    - '443'
  srcSecureTags:
  - name: tagValues/479619031616
    state: EFFECTIVE
priority: 490
ruleTupleCount: 7
targetSecureTags:
- name: tagValues/230424970229
  state: EFFECTIVE

Вернитесь на вкладку сеанса SSH fwpolicy-vpc1-client и повторите попытку:

user@fwpolicy-vpc1-client$ curl fwpolicy-vpc1-www --connect-timeout 2

На этот раз соединение должно истечь, поскольку тег не был добавлен в fwpolicy-vpc1-client . Из Cloud Shell добавьте его и повторите попытку.

gcloud resource-manager tags bindings create \
  --location $zone \
  --tag-value $org_id/tags-vpc1/web-clients \
  --parent \
//compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-vpc1-client

Вернитесь на вкладку сеанса SSH fwpolicy-vpc1-client и повторите попытку, которая теперь должна завершиться успешно.

user@fwpolicy-vpc1-client$ curl fwpolicy-vpc1-www --connect-timeout 2

7. Теги, управляемые IAM, через пиринг сети VPC

В Cloud Shell создайте новый VPC, подсеть и клиент и настройте пиринг сети VPC между сетями:

gcloud compute networks create $prefix-vpc2 --subnet-mode=custom 

gcloud compute networks subnets create $prefix-vpc2-subnet \
   --range=10.0.1.0/24 --network=$prefix-vpc2 --region=$region

gcloud compute instances create $prefix-vpc2-client \
   --subnet=$prefix-vpc2-subnet --no-address --zone $zone

gcloud compute networks peerings create vpc1-to-vpc2 \
   --network=$prefix-vpc1 \
   --peer-project $project_id \
   --peer-network $prefix-vpc2

gcloud compute networks peerings create vpc2-to-vpc1 \
    --network=$prefix-vpc2 \
    --peer-project $project_id \
    --peer-network $prefix-vpc1

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

Создайте правило брандмауэра, которое разрешает входящий SSH-трафик из диапазонов IAP, если оно еще не было определено как часть настройки IAP:

gcloud compute firewall-rules create allow-ssh-ingress-from-iap-vpc2 \
  --direction=INGRESS \
  --action=allow \
  --network=$prefix-vpc2 \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20

Несмотря на то, что теги являются объектами всей организации, ключи тегов связаны с конкретным VPC и поэтому не могут применяться к экземплярам в разных сетях. Таким образом, необходимо создать новый ключ и значение тега, применимые к vpc2:

gcloud resource-manager tags keys create tags-vpc2 \
   --parent organizations/$org_id \
   --purpose GCE_FIREWALL \
   --purpose-data network=$project_id/$prefix-vpc2

gcloud resource-manager tags values create web-clients \
   --parent=$org_id/tags-vpc2

Примените новый тег к экземпляру fwpolicy-vpc2-client :

gcloud resource-manager tags bindings create \
  --location $zone \
  --tag-value $org_id/tags-vpc2/web-clients \
  --parent \
//compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-vpc2-client

При желании перечислите привязки fwpolicy-vpc2-client :

gcloud resource-manager tags bindings list --location $zone --effective --parent //compute.googleapis.com/projects/$project_id/zones/$zone/instances/$prefix-vpc2-client

Ожидаемый результат:

namespacedTagKey: ORGANIZATION_ID/tags-vpc2
namespacedTagValue: ORGANIZATION_ID/tags-vpc2/web-clients
tagKey: tagKeys/916316350251
tagValue: tagValues/633150043992

В Cloud Shell опишите существующее правило политики сетевого брандмауэра, чтобы убедиться, что новые теги не используются:

gcloud compute network-firewall-policies rules describe 500 \
    --firewall-policy $prefix-example \
    --global-firewall-policy

Ожидаемый результат:

---
action: allow
description: allow-web
direction: INGRESS
disabled: false
enableLogging: true
kind: compute#firewallPolicyRule
match:
  layer4Configs:
  - ipProtocol: tcp
    ports:
    - '80'
  - ipProtocol: tcp
    ports:
    - '443'
  srcSecureTags:
  - name: tagValues/479619031616
    state: EFFECTIVE
priority: 500
ruleTupleCount: 6
targetSecureTags:
- name: tagValues/230424970229
  state: EFFECTIVE

Обновите существующее правило брандмауэра, чтобы разрешить теги из одноранговой сети VPC:

gcloud compute network-firewall-policies rules update 500 \
    --firewall-policy $prefix-example \
    --src-secure-tags $org_id/tags-vpc1/web-clients,$org_id/tags-vpc2/web-clients \
    --global-firewall-policy

Опишите правило брандмауэра, чтобы убедиться, что оно было успешно применено и указано как ЭФФЕКТИВНОЕ :

gcloud compute network-firewall-policies rules describe 500 \
    --firewall-policy $prefix-example \
    --global-firewall-policy

Ожидаемый результат:

---
action: allow
description: allow-web
direction: INGRESS
disabled: false
enableLogging: false
kind: compute#firewallPolicyRule
match:
  layer4Configs:
  - ipProtocol: tcp
    ports:
    - '80'
  - ipProtocol: tcp
    ports:
    - '443'
  srcSecureTags:
  - name: tagValues/479619031616
    state: EFFECTIVE
  - name: tagValues/633150043992
    state: EFFECTIVE
priority: 500
ruleTupleCount: 7
targetSecureTags:
- name: tagValues/230424970229
  state: EFFECTIVE

Узнайте IP-адрес fwpolicy-vpc1-www с помощью команды gcloud ниже:

gcloud compute instances list --filter=vpc1-www

Подключитесь к клиенту fwpolicy-vpc2 через SSH и попробуйте свернуть IP-адрес fwpolicy-vpc1 :

user@fwpolicy-vpc2-client$ curl [fwpolicy-vpc1-www_IP] --connect-timeout 2

Вы сможете подключиться к серверу fwpolicy-vpc1-www . Перейдите к следующему разделу, где описаны этапы очистки.

8. Этапы очистки

Из Cloud Shell удалите экземпляры, Cloud NAT и Cloud Router:

gcloud -q compute instances delete $prefix-vpc2-client --zone=$zone

gcloud -q compute instances delete $prefix-vpc1-client --zone=$zone

gcloud -q compute instances delete $prefix-vpc1-www --zone=$zone

gcloud -q compute routers nats delete $prefix-vpc1-cloudnat \
--router=$prefix-vpc1-cr --router-region=$region

gcloud -q compute routers delete $prefix-vpc1-cr --region=$region

Удалите политику брандмауэра глобальной сети и теги:

gcloud -q resource-manager tags values delete \
   $org_id/tags-vpc2/web-clients

gcloud -q resource-manager tags keys delete $org_id/tags-vpc2

gcloud -q resource-manager tags values delete \
   $org_id/tags-vpc1/web-servers

gcloud -q resource-manager tags values delete \
   $org_id/tags-vpc1/web-clients

gcloud -q resource-manager tags keys delete $org_id/tags-vpc1

gcloud -q compute network-firewall-policies associations delete \
     --firewall-policy $prefix-example \
     --name $prefix-vpc1-association \
     --global-firewall-policy

gcloud -q compute network-firewall-policies delete \
   $prefix-example --global

gcloud -q compute firewall-rules delete allow-ssh-ingress-from-iap-vpc1

gcloud -q compute firewall-rules delete allow-ssh-ingress-from-iap-vpc2

Если роли tagAdmin и tagUsers были изменены, выполните следующие действия:

gcloud organizations remove-iam-policy-binding $org_id \
  --member user:[email] --role roles/resourcemanager.tagAdmin

gcloud organizations remove-iam-policy-binding $org_id \
  --member user:[email] --role roles/resourcemanager.tagUser

Наконец, удалите пиринги сетей VPC, подсети и сети VPC:

gcloud -q compute networks peerings delete vpc1-to-vpc2 \
    --network $prefix-vpc1

gcloud -q compute networks peerings delete vpc2-to-vpc1 \
    --network $prefix-vpc2

gcloud -q compute networks subnets delete $prefix-vpc1-subnet \
    --region $region

gcloud -q compute networks subnets delete $prefix-vpc2-subnet \
    --region $region

gcloud -q compute networks delete $prefix-vpc1

gcloud -q compute networks delete $prefix-vpc2

9. Поздравляем!

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