1. Przegląd
W tym module dowiesz się, jak ograniczyć dostęp do usługi Cloud Run i zezwolić tylko na żądania z zadania działającego lokalnie lub w sieci VPC projektu. Możesz używać 2 warstw kontroli dostępu: ustawień dostępu przychodzącego i zasad zarządzania tożsamościami i dostępem (IAM).
Ustawienia ruchu przychodzącego
Ustawienia wejścia umożliwiają filtrowanie żądań na podstawie ich pochodzenia w sieci (wewnętrznego lub zewnętrznego). Domyślnie wszystkie żądania są przepuszczane, w tym te pochodzące z publicznego internetu.
Zasady IAM
Zasady IAM umożliwiają filtrowanie żądań na podstawie tożsamości nadawcy i są powszechnie używane do uwierzytelniania żądań między usługami.
Z tego modułu dowiesz się, jak i kiedy używać ustawień wejścia.
Hosty lokalne łączą się przez sieć VPC
W tym module zasymulujemy obciążenie lokalne. Aby połączyć hosta lokalnego z Cloud Run, skonfiguruj prywatny dostęp do Google dla hostów lokalnych. Obejmuje to skonfigurowanie bramy Cloud VPN w sieci VPC, jak pokazano poniżej.
Symulowanie zbioru zadań lokalnych za pomocą serwera przesiadkowego w sieci VPC
W tym module zasymulujesz wysyłanie żądań z hosta lokalnego, wysyłając żądania z maszyny wirtualnej Compute Engine w sieci VPC, jak pokazano tutaj.
Maszyna wirtualna Compute Engine, której użyjesz jako serwera przesiadkowego, ma takie samo pochodzenie sieciowe jak brama Cloud VPN, dlatego możesz jej używać do symulowania wysyłania żądań z obciążenia lokalnego.
2. Konfiguracja i wymagania
Samodzielne konfigurowanie środowiska
- Zaloguj się w konsoli Google Cloud i utwórz nowy projekt lub użyj istniejącego. Jeśli nie masz jeszcze konta Gmail lub Google Workspace, musisz je utworzyć.
- Nazwa projektu to wyświetlana nazwa dla uczestników tego projektu. Jest to ciąg znaków, który nie jest używany przez interfejsy API Google. Możesz ją zaktualizować w dowolnym momencie.
- Identyfikator projektu jest unikalny we wszystkich projektach Google Cloud i nie można go zmienić po ustawieniu. Konsola Cloud automatycznie generuje unikalny ciąg znaków. Zwykle nie musisz się nim przejmować. W większości przewodników programowania musisz odwoływać się do identyfikatora projektu (zwykle jest on oznaczony jako
PROJECT_ID). Jeśli wygenerowany identyfikator Ci się nie podoba, możesz wygenerować inny losowy identyfikator. Możesz też spróbować utworzyć własny adres i sprawdzić, czy jest dostępny. Po tym kroku nie można go zmienić i będzie obowiązywać przez cały czas trwania projektu. - Warto wiedzieć, że istnieje trzecia wartość, numer projektu, której używają niektóre interfejsy API. Więcej informacji o tych 3 wartościach znajdziesz w dokumentacji.
- Następnie musisz włączyć płatności w konsoli Cloud, aby korzystać z zasobów i interfejsów API Google Cloud. Ukończenie tego laboratorium nie powinno wiązać się z dużymi kosztami, a nawet z żadnymi. Aby wyłączyć zasoby i uniknąć naliczania opłat po zakończeniu tego samouczka, możesz usunąć utworzone zasoby lub cały projekt. Nowi użytkownicy Google Cloud mogą skorzystać z programu bezpłatnego okresu próbnego, w którym mają do dyspozycji środki w wysokości 300 USD.
Konfiguracja środowiska
- Ustaw zmienną środowiskową na identyfikator projektu, aby móc jej używać w późniejszych poleceniach:
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1
export ZONE=us-central1-a
- Włącz interfejsy API wymagane do wykonania tego ćwiczenia.
gcloud services enable \
run.googleapis.com \
cloudbuild.googleapis.com \
compute.googleapis.com \
artifactregistry.googleapis.com
- Sklonuj repozytorium przykładowej aplikacji i przejdź do katalogu.
git clone https://github.com/GoogleCloudPlatform/cymbal-eats.git
cd cymbal-eats/partner-registration-service
- Ustawianie domyślnego regionu i strefy dla Compute Engine i Cloud Run
gcloud config set compute/region ${REGION}
gcloud config set run/region ${REGION}
gcloud config set compute/zone ${ZONE}
3. Wdrażanie usługi
Najpierw wdrożysz usługę i pozostawisz ją dostępną publicznie. Gdy potwierdzisz, że możesz wysyłać żądania z przeglądarki, zablokujemy usługę i umożliwimy tylko żądania z wewnętrznych źródeł sieciowych.
Gdy uruchomisz to polecenie, wykonaj te instrukcje:
- Lokalizacja kodu źródłowego (...): sprawdź, czy jesteś w katalogu partner-registration-service, i naciśnij Enter, aby zaakceptować wartość domyślną
- Nazwa usługi (partner-registration-service): naciśnij Enter, aby zaakceptować domyślną nazwę
- Zezwalać na nieuwierzytelnione wywołania usługi [partner-registration-service] (T/N)? T
gcloud run deploy
Po zakończeniu tego polecenia wyświetli się adres URL usługi Cloud Run. Dane wyjściowe będą podobne do tych:
Service [partner-registration-service] revision [partner-registration-service-00001-haz] has been deployed and is serving 100 percent of traffic. Service URL: https://partner-registration-service-ssssssssss-uc.a.run.app
Otwórz adres URL usługi w przeglądarce. Powinny się wyświetlić te dane wyjściowe:
Partner registration service: RUNNING
Skonfiguruj usługę tak, aby zezwalała tylko na żądania wewnętrzne.
Teraz użyjesz ustawień ruchu przychodzącego usługi Cloud Run, aby zezwolić tylko na żądania ze źródeł wewnętrznych. Źródła wewnętrzne obejmują zasoby w sieciach VPC, które znajdują się w tym samym projekcie (lub granicy Ustawień usługi VPC) co usługa Cloud Run, co idealnie pasuje do naszego przypadku użycia.
Żądania z innych usług Google Cloud są uznawane za wewnętrzne, nawet jeśli nie należą do sieci VPC. Są to na przykład Pub/Sub i Workflows.
Żądania z tych źródeł pozostają w sieci Google, nawet jeśli uzyskują dostęp do Twojej usługi pod adresem URL run.app, a dostęp publiczny jest zabroniony.
Zaktualizuj usługę, aby zezwalać tylko na żądania wewnętrzne:
gcloud run services update partner-registration-service --ingress=internal
Jeśli ponownie otworzysz adres URL usługi, pojawi się komunikat „Błąd: zabroniony – dostęp jest zabroniony”.
Ponieważ przeglądarka wysyła żądanie z zewnętrznego źródła sieci, a nie ze źródła wewnętrznego w projekcie w chmurze Google, jest to dokładnie to, czego można się spodziewać. Twoja usługa jest teraz bezpieczniejsza.
4. Tworzenie maszyny wirtualnej Compute Engine jako serwera przesiadkowego
Następnym krokiem jest symulowanie żądań z serwera lokalnego za pomocą bramy Cloud VPN. W tym celu utwórz w sieci VPC instancję Compute Engine, która będzie pełnić funkcję serwera przeskoku:
gcloud compute instances create jump-server --scopes=https://www.googleapis.com/auth/cloud-platform
Wynik tego polecenia powinien być podobny do tego:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS jump-server us-central1-a n1-standard-1 10.128.0.10 34.170.108.8 RUNNING
Wysyłanie żądania z instancji Compute Engine do usługi
Teraz otworzysz terminal na maszynie wirtualnej i wyślesz żądanie bezpośrednio z maszyny w sieci VPC.
Jeśli po uruchomieniu tego polecenia pojawi się prośba o skonfigurowanie SSH w Cloud Shell, postępuj zgodnie z instrukcjami:
gcloud compute ssh jump-server
Pobierz adres URL usługi Cloud Run za pomocą tego polecenia:
gcloud run services describe partner-registration-service --region us-central1
Pierwsze kilka wierszy danych wyjściowych powinno wyglądać tak:
✔ Service partner-registration-service in region us-central1 URL: https://partner-registration-service-ssssssssss-uc.a.run.app Ingress: internal
Teraz skopiuj adres URL i wyślij żądanie z instancji Compute Engine za pomocą polecenia curl. Ta prośba powinna się powieść, ponieważ instancja maszyny wirtualnej działa w sieci VPC Twojego projektu – jest to źródło wewnętrzne.
export SERVICE_URL=https://
curl ${SERVICE_URL}
Dane wyjściowe powinny wyglądać tak:
Partner registration service: RUNNING
5. A co z kontrolą dostępu opartą na uprawnieniach?
W tym module dowiesz się, jak i kiedy używać ustawień wejścia. Ustawienia wejścia to świetny pierwszy krok, jeśli łączysz zadanie lokalne z Cloud Run.
Wdrożenie kontroli dostępu opartej na uprawnieniach wymaga więcej wysiłku, zwłaszcza jeśli wywołujesz funkcję z hosta lokalnego:
- IAM wymaga zarządzania długoterminowymi danymi logowania do konta usługi na hoście
- IAM wymaga wprowadzenia zmian w kodzie, aby podpisywać żądania za pomocą danych logowania konta usługi.
Google zaleca wielowarstwowe podejście do kontroli dostępu. Używanie ustawień wejścia do ograniczania dostępu tylko do hostów wewnętrznych to świetny pierwszy krok, ale nie poprzestawaj na tym.
6. Gratulacje!
Gratulacje! Codelab został ukończony.
Co dalej?
Poznaj inne ćwiczenia z programowania Cymbal Eats:
- Aktywowanie Cloud Workflows za pomocą Eventarc
- Aktywowanie przetwarzania zdarzeń z Cloud Storage
- Łączenie z prywatną instancją Cloud SQL z poziomu Cloud Run
- Łączenie z w pełni zarządzanymi bazami danych z Cloud Run
- Zabezpieczanie aplikacji bezserwerowej za pomocą funkcji Identity Aware Proxy (IAP)
- Aktywowanie zadań Cloud Run za pomocą usługi Cloud Scheduler
- Bezpieczne wdrażanie w Cloud Run
- Łączenie z prywatną instancją AlloyDB z Autopilota w GKE
Czyszczenie danych
Aby uniknąć obciążenia konta Google Cloud opłatami za zasoby zużyte w tym samouczku, możesz usunąć projekt zawierający te zasoby lub zachować projekt i usunąć poszczególne zasoby.
Usuwanie projektu
Najprostszym sposobem na uniknięcie płatności jest usunięcie projektu utworzonego w tym samouczku.
Przydatne odniesienia
Poniżej znajdziesz dodatkowe materiały, które pomogą Ci dowiedzieć się więcej o 2 warstwach kontroli dostępu w Cloud Run.