Hierarchiczne zasady zapory sieciowej z tagami zarządzanymi przez IAM

1. Wprowadzenie

Cloud Next Generation Firewall (NGFW)

Cloud Next Generation Firewall to w pełni rozproszona usługa zapory sieciowej z zaawansowanymi funkcjami ochrony, mikrosegmentacją i wszechstronnym zasięgiem, która chroni zbiory zadań Google Cloud przed atakami wewnętrznymi i zewnętrznymi.

Cloud NGFW ma następujące korzyści:

Rozproszona usługa zapory sieciowej: Cloud NGFW zapewnia stanowe, w pełni rozproszone egzekwowanie zasad na poziomie hosta w przypadku każdego zbioru zadań, aby umożliwić architekturę zabezpieczeń opartą na zasadzie „zero zaufania”.
Uproszczona konfiguracja i wdrożenie: Cloud NGFW implementuje zasady zapory sieciowej i hierarchicznej, które można dołączyć do węzła hierarchii zasobów. Zapewniają one spójne działanie zapory sieciowej w całej hierarchii zasobów Google Cloud.
Szczegółowa kontrola i mikrosegmentacja: połączenie zasad zapory sieciowej i tagów zarządzanych przez Identity and Access Management (IAM) zapewnia szczegółową kontrolę ruchu północ-południe i wschód-zachód, aż do pojedynczej maszyny wirtualnej, w sieciach prywatnego środowiska wirtualnego w chmurze (VPC).

Zasady zapory sieciowej

Zasada zapory sieciowej działa jako kontener reguł zapory sieciowej. Reguły zdefiniowane w zasadach zapory sieciowej nie są egzekwowane w żadnym miejscu, dopóki zasady nie zostaną powiązane z siecią VPC. Każda sieć VPC może mieć powiązaną z nią jedną zasadę zapory sieciowej. Zasady zapory sieciowej obsługują tagi zarządzane przez IAM (lub po prostu tagi) w regułach zapory sieciowej i mogą być używane do przypisywania tożsamości do zbioru zadań.

Udostępnianie zasad zapory sieciowej w różnych sieciach i integracja z tagami zarządzanymi przez uprawnienia znacznie upraszczają konfigurację i zarządzanie zaporami.

Wraz z wprowadzeniem zasady zapory sieciowej zasady zapory sieciowej Google Cloud składają się teraz z tych komponentów:

Hierarchiczne zasady zapory sieciowej są obsługiwane w węzłach organizacji i folderów w hierarchii zasobów, natomiast reguły zapory sieciowej VPC i zasady zapory sieciowej są stosowane na poziomie VPC. Duża różnica między regułami zapory sieciowej VPC a zasadami zapory sieciowej polega na tym, że reguły zapory sieciowej VPC można stosować tylko do jednej sieci VPC, a zasady zapory sieciowej można dołączać do jednej sieci VPC lub grupy sieci VPC. Zapewniają one też inne korzyści, takie jak aktualizacje zbiorcze.

W tym module przetestujemy hierarchiczne zasady zapory sieciowej i globalne zasady zapory sieciowej.

Oprócz tego każda sieć VPC ma domyślne reguły zapory sieciowej:

Reguła ruchu wychodzącego, której działanie to zezwolenie, a miejsce docelowe to 0.0.0.0/0
Reguła ruchu przychodzącego, której działanie to odmowa, a źródło to 0.0.0.0/0

Domyślnie sekwencja egzekwowania jest wyświetlana na tym diagramie:

Tagi zarządzane przez IAM

Nowe tagi zintegrowane z regułami zasad zapory sieciowej to zasoby w postaci par klucz-wartość zdefiniowane na poziomie organizacji lub projektu w hierarchii zasobów Google Cloud. Taki tag zawiera kontrolę dostępu w uprawnieniach, która określa, kto może wykonywać jakie działania na tagu. Uprawnienia IAM pozwalają na przykład określić, które podmioty zabezpieczeń mogą przypisywać wartości do tagów, a które mogą dołączać tagi do zasobów. Gdy tag zostanie zastosowany do zasobu, reguły zasad zapory sieciowej mogą go używać do zezwalania na ruch i odrzucania go.

Tagi są zgodne z modelem dziedziczenia zasobów Google Cloud, co oznacza, że tagi i ich wartości są przekazywane w hierarchii z elementów nadrzędnych. Dzięki temu tagi można tworzyć w jednym miejscu, a potem używać w innych folderach i projektach w całej hierarchii zasobów. Więcej informacji o tagach i ograniczeniach dostępu znajdziesz na tej stronie.

Nie należy mylić tagów z tagami sieci, które są ciągami znaków, które można dodać do instancji Compute Engine. Są one powiązane z instancją i znikają po jej wycofaniu. Reguły zapory sieciowej VPC mogą zawierać tagi sieci, ale ponieważ nie są traktowane jako zasoby w chmurze, nie podlegają kontroli dostępu IAM. Szczegółowe informacje o różnicach znajdziesz na tej stronie.

2. Czego się nauczysz

Jak tworzyć tagi zarządzane przez IAM do użycia z Cloud NGFW i o zasięgu globalnym.
Jak dołączać tagi do maszyn wirtualnych.
Jak utworzyć hierarchiczną zasadę zapory sieciowej i powiązać ją z folderem.
Jak utworzyć regułę zapory sieciowej w hierarchicznej zasadzie zapory sieciowej i określić źródło oraz miejsce docelowe za pomocą tagów zarządzanych przez IAM.

3. Ogólna architektura modułu

Organizacja i foldery:

Utworzysz 2 foldery, folder1 i folder2, bezpośrednio w organizacji.

Projekty:

W folder1 utworzysz projekt hosta. Ten projekt będzie zawierać sieć współdzielonego środowiska VPC.
W folder2 utworzysz projekt usługi. Ten projekt będzie zawierać maszyny wirtualne korzystające ze współdzielonego środowiska VPC.

Nawiązywanie kontaktów:

W głównym projekcie zostanie utworzona sieć VPC o nazwie mynet, która zostanie skonfigurowana jako współdzielone środowisko VPC. Umożliwia to zasobom w projekcie usługi korzystanie z sieci.
W projekcie usługi zostaną utworzone 2 maszyny wirtualne, które będą połączone ze współdzielonym środowiskiem VPC mynet.

Tagi zarządzane przez IAM:

Utworzysz tag zarządzany przez IAM o nazwie http_tags z 2 wartościami o nazwach http_server i http_client na poziomie organizacji. Te tagi i wartości będą używane do identyfikowania maszyn wirtualnych i stosowania do nich reguł zapory sieciowej.

Zasady zapory sieciowej:

Zostaną utworzone hierarchiczne zasady zapory sieciowej, które zostaną powiązane z folder1. Reguła w tych zasadach będzie używać tagów zarządzanych przez IAM, aby zezwalać na ruch z http-client do http-server na porcie 80.
W projekcie hosta zostanie utworzona zasada zapory sieciowej, która będzie powiązana z siecią VPC mynet. Te zasady będą zawierać regułę zezwalającą na dostęp SSH do maszyn wirtualnych za pomocą IAP na potrzeby testów.

4. Kroki przygotowawcze

Najpierw skonfiguruj w organizacji Google Cloud niezbędne role uprawnień, infrastrukturę sieciową i instancje.

Role uprawnień wymagane do pracy w laboratorium

Zaczynamy od przypisania wymaganych ról uprawnień do konta GCP na poziomie organizacji.

Administrator organizacji (roles/resourcemanager.organizationAdmin) Ta rola umożliwia zarządzanie zasadami uprawnień oraz wyświetlanie zasad organizacji dla organizacji, folderów i projektów.
Administrator tagów(roles/resourcemanager.tagAdmin) Ta rola umożliwia tworzenie, aktualizowanie i usuwanie bezpiecznych tagów.
Rola Użytkownik tagu (roles/resourcemanager.tagUser) Ta rola umożliwia dostęp do listy bezpiecznych tagów i zarządzanie ich powiązaniami z zasobami.
Rola Administrator zasad zapory sieciowej organizacji Compute (roles/compute.orgFirewallPolicyAdmin) – ta rola zapewnia pełną kontrolę nad zasadami zapory sieciowej organizacji Compute Engine.
Rola Administrator zasobów organizacji Compute (roles/compute.orgSecurityResourceAdmin) – ta rola zapewnia pełną kontrolę nad powiązaniami zasad zapory sieciowej Compute Engine z organizacją lub folderem.
Administrator sieci Compute (roles/compute.networkAdmin) Ta rola zapewnia pełną kontrolę nad zasobami sieciowymi Compute Engine.
Administrator instancji Compute( beta) (roles/compute.instanceAdmin) Ta rola zapewnia pełną kontrolę nad zasobami instancji Compute Engine.
Administrator logowania (roles/logging.admin) Ta rola daje dostęp do wszystkich uprawnień związanych z logowaniem i uprawnień zależnych.
Administrator konta usługi (roles/iam.serviceAccountAdmin) – ta rola umożliwia tworzenie kont usługi i zarządzanie nimi.
Administrator wykorzystania usług (roles/serviceusage.serviceUsageAdmin) – ta rola umożliwia włączanie, wyłączanie i sprawdzanie stanu usług, sprawdzanie operacji, a także zużywanie limitu i płatnych usług w ramach projektu konsumenta.
Administrator współdzielonego środowiska VPC w Compute (roles/compute.xpnAdmin) Ta rola umożliwia zarządzanie udostępnioną siecią VPC (XPN).

Utwórz foldery i projekty

W Cloud Shell wykonaj te czynności, aby utworzyć folder1 i folder2:

gcloud auth login

export org_id=$(gcloud organizations list --format='value(ID)')
export BILLING_ACCOUNT_ID=$(gcloud billing accounts list --format='value(ACCOUNT_ID)')
export folder1=[FOLDER1 NAME]
export folder2=[FOLDER2 NAME]
export hostproject=[HOST PROJECT NAME]
export serviceproject=[SERVICE PROJECT NAME]
export regionname=[REGION NAME]
export zonename=[COMPUTE ZONE NAME]

gcloud resource-manager folders create --display-name=$folder1 --organization=$org_id
export folder1_id=$(gcloud resource-manager folders list --organization=$org_id --filter="displayName=$folder1" --format="value(ID)")
gcloud resource-manager folders create --display-name=$folder2 --organization=$org_id
export folder2_id=$(gcloud resource-manager folders list --organization=$org_id --filter="displayName=$folder2" --format="value(ID)")

W Cloud Shell wykonaj te czynności, aby utworzyć projekt hosta w folder1:

gcloud projects create  --name=$hostproject --folder=$folder1_id

Zobaczysz te informacje. Naciśnij Y, aby utworzyć projekt z nowym identyfikatorem projektu.

No project ID provided.

Use [NEW-PROJECT-ID] as project ID (Y/n)?

Zanotuj identyfikator projektu. W Cloud Shell wykonaj te czynności, aby wyeksportować go do hostproject_id:

export hostproject_id=[HOSTPROJECT ID]

W Cloud Shell wykonaj te czynności, aby połączyć projekt hosta z kontem rozliczeniowym:

gcloud billing projects link $hostproject_id \
--billing-account=$BILLING_ACCOUNT_ID

W Cloud Shell wykonaj te czynności, aby utworzyć projekt usługi w folder2:

gcloud projects create  --name=$serviceproject --folder=$folder2_id

Zobaczysz te informacje. Naciśnij Y, aby utworzyć projekt z nowym identyfikatorem projektu.

No project ID provided.

Use [NEW-PROJECT-ID] as project ID (Y/n)?

Zanotuj identyfikator projektu. W Cloud Shell wykonaj te czynności, aby wyeksportować go do serviceproject_id:

export serviceproject_id=[SERVICEPROJECT ID]

Aby połączyć projekt usługi z kontem rozliczeniowym, wykonaj w Cloud Shell te czynności:

gcloud billing projects link $serviceproject_id \
--billing-account=$BILLING_ACCOUNT_ID

Tworzenie tagów zarządzanych przez IAM

Tag to para klucz-wartość, którą można dołączyć do organizacji, folderu lub projektu. Więcej informacji znajdziesz w sekcjach Tworzenie tagów i zarządzanie nimi oraz Wymagane uprawnienia.

Tworzymy 1 tag na poziomie organizacji, http-tags. Przeznaczeniem tagu jest użycie w Cloud NGFW. Nie ograniczamy zakresu do jednej sieci – tag ma zakres globalny. Później zastosujemy tag do maszyn wirtualnych utworzonych w projekcie usługi w sekcji folder2.

W Cloud Shell wykonaj te czynności:

gcloud resource-manager tags keys create http_tags \
    --parent=organizations/$org_id \
    --purpose GCE_FIREWALL \
    --purpose-data organization=auto

Podczas tworzenia maszyny wirtualnej użyjemy identyfikatora klucza tagu do dodania do niej adnotacji. Aby uzyskać identyfikator klucza tagu, wykonaj w Cloud Shell te czynności:

export http_tags_id=$(gcloud resource-manager tags keys describe $org_id/http_tags --format="value(name)")
echo $http_tags_id

W Cloud Shell wykonaj te czynności, aby utworzyć 2 nowe wartości tagów: http_server i http_client:

 gcloud resource-manager tags values create http_server \
      --parent $org_id/http_tags
 gcloud resource-manager tags values create http_client \
      --parent $org_id/http_tags

Podczas tworzenia maszyny wirtualnej użyjemy identyfikatora tagu i identyfikatora wartości tagu, aby dodać do niej adnotację. W Cloud Shell wykonaj te czynności, aby uzyskać identyfikator wartości tagu http_server i http_client:

export http_tags_http_server_id=$(gcloud resource-manager tags values describe $org_id/http_tags/http_server --format="value(name)")
echo $http_tags_http_server_id

export http_tags_http_client_id=$(gcloud resource-manager tags values describe $org_id/http_tags/http_client --format="value(name)")
echo $http_tags_http_client_id

Włączanie interfejsów API w projekcie hosta i projekcie usługi

W Cloud Shell wykonaj te czynności:

gcloud services enable compute.googleapis.com --project=$serviceproject_id
gcloud services enable compute.googleapis.com --project=$hostproject_id

Tworzenie sieci VPC w głównym projekcie

W projekcie hosta utwórz sieć VPC w trybie podsieci niestandardowej. W Cloud Shell wykonaj te czynności:

gcloud compute networks create mynet \
    --subnet-mode=custom \
    --project=$hostproject_id

Tworzenie podsieci w projekcie głównym

W Cloud Shell wykonaj te czynności, aby utworzyć podsieć IPv4:

gcloud compute networks subnets create mysubnet \
    --network=mynet \
    --range=10.0.0.0/28 \
    --region=$regionname \
    --project=$hostproject_id

Włączanie współdzielonego środowiska VPC w głównym projekcie

W Cloud Shell wykonaj te czynności, aby włączyć współdzielone środowisko VPC w głównym projekcie:

gcloud compute shared-vpc enable $hostproject_id

Dołączanie projektu usługi do współdzielonego środowiska VPC w głównym projekcie

W Cloud Shell wykonaj te czynności, aby przyłączyć projekt usługi do współdzielonego środowiska VPC w głównym projekcie:

gcloud compute shared-vpc associated-projects add $serviceproject_id --host-project=$hostproject_id

Tworzenie routera Cloud Router i Cloud NAT w projekcie hosta

Cloud NAT umożliwia maszynom wirtualnym wychodzący ruch internetowy, dzięki czemu mogą pobierać i instalować aplikacje.

gcloud compute routers create $regionname-cr \
   --network=mynet \
   --region=$regionname \
   --project=$hostproject_id
gcloud compute routers nats create $regionname-nat \
    --router=$regionname-cr \
    --region=$regionname \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips \
    --project=$hostproject_id

Tworzenie instancji w projekcie usługi

W projekcie usługi utwórz 2 instancje w podsieciach utworzonych właśnie we współdzielonym środowisku VPC w głównym projekcie. Jedna instancja ma nazwę http-server, a tag http_tags oznaczamy wartością http_server. Drugi element ma nazwę http-client, a tag http_tags oznaczamy wartością http_client. Uruchom w Cloud Shell te polecenia:

gcloud compute instances create http-client \
    --project=$serviceproject_id \
   --subnet=projects/$hostproject_id/regions/$regionname/subnetworks/mysubnet \
    --zone=$zonename \
    --no-address \
    --resource-manager-tags=$http_tags_id=$http_tags_http_client_id

gcloud compute instances create http-server \
    --project=$serviceproject_id \
    --subnet=projects/$hostproject_id/regions/$regionname/subnetworks/mysubnet \
    --zone=$zonename \
    --no-address \
    --resource-manager-tags=$http_tags_id=$http_tags_http_server_id \
    --metadata startup-script='#! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    a2enmod ssl
    sudo a2ensite default-ssl
    echo "I am a Http Server." | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Zapisz wewnętrzny adres IP instancji http-server. Użyjemy go w dalszym kroku testowania reguły zapory sieciowej.

export http_server_ip=$(gcloud compute instances describe http-server --zone $zonename --format='value(networkInterfaces[0].networkIP)' --project $serviceproject_id)
echo $http_server_ip

5. Tworzenie globalnej zasady zapory sieciowej w projekcie hosta

Utworzymy globalną zasadę zapory sieciowej w projekcie hosta i powiążemy ją ze współdzielonym środowiskiem VPC w projekcie hosta.

gcloud config set project $hostproject_id
gcloud compute network-firewall-policies create  mynet-fw-policy \
--global \
--project=$hostproject_id
gcloud compute network-firewall-policies associations create \
    --firewall-policy=mynet-fw-policy \
    --network=mynet \
    --name=mynet-fw-policy \
    --global-firewall-policy \
    --project=$hostproject_id

Aby umożliwić IAP połączenie z instancjami maszyn wirtualnych, utwórz regułę zapory sieciowej w zasadach zapory sieciowej:

Dotyczy wszystkich instancji maszyn wirtualnych, które mają być dostępne przez IAP.
Zezwala na ruch przychodzący z zakresu adresów IP 35.235.240.0/20. Ten zakres zawiera wszystkie adresy IP, których IAP używa do przekierowywania TCP.

gcloud compute network-firewall-policies rules create 1000 \
    --action=ALLOW \
    --firewall-policy=mynet-fw-policy \
    --description="mynet-allow-iap" \
    --direction=INGRESS \
    --src-ip-ranges=35.235.240.0/20 \
    --layer4-configs=tcp:22  \
    --global-firewall-policy \
    --project=$hostproject_id

W konsoli możesz przejść do projektu hosta i znaleźć nowo utworzoną globalną zasadę zapory sieciowej w sekcji Zasady zapory sieciowej. Nowo utworzoną regułę zapory sieciowej możesz sprawdzić w zasadach zapory sieciowej. Aby przejść do konsoli, kliknij ten link. W selektorze projektów w konsoli wybierz projekt główny.

6. Testowanie dostępu z maszyny wirtualnej klienta HTTP do maszyny wirtualnej serwera HTTP

Połącz się przez SSH z maszyną wirtualną o nazwie http-client i sprawdź, czy ma ona dostęp do http-server na porcie http 80.

W Cloud Shell wykonaj te czynności:

gcloud compute ssh \
    --zone=$zonename "http-client" \
    --tunnel-through-iap \
    --project=$serviceproject_id

Użyj polecenia curl, aby uzyskać dostęp do serwera WWW.

curl -m 10 [http_server_ip]

Zobaczysz wynik polecenia curl. Nie ma reguły zapory sieciowej dotyczącej ruchu przychodzącego, która zezwalałaby na port 80 dla http-server.

Przekroczono limit czasu połączenia po 10000 milisekundach.

Wróć do Cloud Shell, zamykając sesję SSH.

exit

7. Tworzenie hierarchicznej zasady zapory sieciowej i reguł zapory sieciowej

Utworzymy hierarchiczne zasady zapory sieciowej w folder1 i powiążemy je z folder1. Reguły zapory sieciowej w ramach zasady będą stosowane w projekcie hosta w sekcji folder1.

Tworzenie hierarchicznych zasad zapory sieciowej

gcloud compute firewall-policies create \
  --folder=$folder1_id \
  --short-name=my-folder1-fw-policy

Tworzenie reguły zapory sieciowej w hierarchicznych zasadach zapory sieciowej

Reguła zezwala maszynom wirtualnym z wartością tagu http_tags/http_client na dostęp do maszyn wirtualnych z wartością tagu http_tags/http_server na porcie TCP 80.

gcloud compute firewall-policies rules create 100 \
  --organization=$org_id \
  --firewall-policy my-folder1-fw-policy \
  --direction=INGRESS \
  --layer4-configs=tcp:80 \
  --action=allow \
  --src-secure-tags=$org_id/http_tags/http_client \
  --target-secure-tags=$org_id/http_tags/http_server \
  --description=folder1-allow-http

Powiązywanie hierarchicznych zasad zapory sieciowej z folderem1

gcloud compute firewall-policies associations create \
   --firewall-policy=my-folder1-fw-policy \
   --folder=$folder1_id \
   --name=my-folder1-fw-policy\
   --organization=$org_id

W konsoli możesz przejść do sekcji folder1 i znaleźć nowo utworzone hierarchiczne zasady zapory sieciowej w sekcji Zasady zapory sieciowej. Zasady zapory sieciowej są widoczne w sekcji „Zasady zapory sieciowej obowiązujące w tym folderze”. Nowo utworzoną regułę zapory sieciowej możesz sprawdzić w hierarchicznej zasadzie zapory sieciowej. Aby przejść do konsoli, kliknij ten link. Sprawdź, czy w selektorze projektów w konsoli wybrano folder1.

8. Testowanie dostępu z maszyny wirtualnej klienta HTTP do maszyny wirtualnej serwera HTTP

Sprawdź obowiązujące zasady zapory sieciowej zastosowane do współdzielonego środowiska VPC w głównym projekcie.

W Cloud Shell wykonaj te czynności:

gcloud compute networks get-effective-firewalls mynet --project=$hostproject_id

Odziedziczone hierarchiczne zasady zapory sieciowej będą wyglądać tak:

TYPE: org-firewall
FIREWALL_POLICY_NAME: <NUMBER_FOR_YOUR_FW_POLICY>
FIREWALL_POLICY_PRIORITY: 
PRIORITY: 100
ACTION: ALLOW
DIRECTION: INGRESS
DISABLED: False
IP_RANGES:

You will see the network firewall policy to the VPC like this:
TYPE: network-firewall-policy
FIREWALL_POLICY_NAME: mynet-fw-policy
FIREWALL_POLICY_PRIORITY: 1000
PRIORITY: 1000
ACTION: ALLOW
DIRECTION: INGRESS
DISABLED: False
IP_RANGES: 35.235.240.0/20

Połącz się przez SSH z maszyną wirtualną o nazwie http-client i sprawdź, czy ma ona dostęp do http-server na porcie http 80.

W Cloud Shell wykonaj te czynności:

gcloud compute ssh \
    --zone=$zonename "http-client" \
    --tunnel-through-iap \
    --project=$serviceproject_id

Użyj polecenia curl, aby uzyskać dostęp do serwera WWW.

curl [http_server_ip]

Polecenie curl zwróci odpowiedź z http-server.

I am a Http Server.

Reguła zapory sieciowej dotycząca ruchu przychodzącego z hierarchicznych zasad zapory sieciowej zezwala na dostęp z http-client do http-server na porcie 80.

Wróć do Cloud Shell, zamykając sesję SSH.

exit

9. Czyszczenie danych

Zwalnianie miejsca na maszynach wirtualnych w projekcie usługi

W Cloud Shell wykonaj te czynności:

gcloud compute instances delete http-server --zone $zonename --project=$serviceproject_id
gcloud compute instances delete http-client --zone $zonename --project=$serviceproject_id

Zwalnianie miejsca w hierarchicznych zasadach zapory sieciowej

W Cloud Shell wykonaj te czynności:

gcloud compute firewall-policies associations delete my-folder1-fw-policy \
   --firewall-policy=my-folder1-fw-policy \
   --organization=$org_id
gcloud compute firewall-policies rules delete 100 \
  --organization=$org_id \
  --firewall-policy=my-folder1-fw-policy
gcloud compute firewall-policies delete my-folder1-fw-policy \
  --organization=$org_id

Usuwanie tagów na poziomie organizacji

W Cloud Shell wykonaj te czynności:

gcloud resource-manager tags values delete $http_tags_http_server_id
gcloud resource-manager tags values delete $http_tags_http_client_id
gcloud resource-manager tags keys delete $http_tags_id

Zwolnij miejsce w projekcie hosta

W Cloud Shell wykonaj te czynności:

gcloud compute shared-vpc associated-projects remove $serviceproject_id --host-project=$hostproject_id 
gcloud compute shared-vpc disable $hostproject_id
gcloud projects delete $hostproject_id

Zwalnianie miejsca w projekcie usługi

W Cloud Shell wykonaj te czynności:

gcloud projects delete $serviceproject_id

Zwalnianie miejsca w folderach

W Cloud Shell wykonaj te czynności:

gcloud resource-manager folders delete $folder1_id
gcloud resource-manager folders delete $folder2_id

10. Gratulacje

Udało Ci się przetestować hierarchiczne zasady zapory sieciowej z tagami zarządzanymi przez IAM.