Logo
GCP Vertex AI IAM MLOps

Vertex AI predykcja 403 odmowa uprawnień: aiplatform.endpoints.predict i konto usługi

Rozwiązanie błędu 403 PermissionDenied na aiplatform.endpoints.predict: identyfikacja wołającej tożsamości, nadanie roli Vertex AI User na właściwym projekcie oraz wykluczenie błędnej ścieżki zasobu lub projektu, zanim zaczniesz szukać winy w IAM.

Jerzy Kopaczewski ·
Twoje wywołanie endpointu predykcji Vertex AI kończy się błędem 403 Permission 'aiplatform.endpoints.predict' denied. Endpoint jest wdrożony i zdrowy, ale tożsamość wykonująca żądanie nie ma prawa go wołać. Rozwiązanie to niemal zawsze jedno z trzech: wołające konto usługi nie ma roli Vertex AI, poświadczenia wskazują zły projekt, albo ścieżka zasobu w żądaniu jest błędna. Ten runbook przechodzi przez nie po kolei.

Ten runbook dotyczy błędu uprawnień predykcji. Jeśli sam endpoint nie chce się wdrożyć, zobacz runbook o wdrożeniu. Jeśli wywołania są odrzucane z 429, a nie 403, zobacz runbook o predykcji 429. Po pomoc praktyczną umów konsultację.

Objawy

Wywołanie zwraca 403 z nazwą uprawnienia aiplatform.endpoints.predict i zasobu, na którym odmówiono.

google.api_core.exceptions.PermissionDenied: 403 Permission
'aiplatform.endpoints.predict' denied on resource
'//aiplatform.googleapis.com/projects/PROJECT/locations/us-central1/endpoints/ENDPOINT_ID'
(or it may not exist).

Obserwowalny skutek:

  • To samo żądanie działa z Twojego konta użytkownika (które ma szerokie role), ale kończy się błędem z konta usługi lub zadania CI
  • Endpoint jest widoczny i zdrowy w konsoli, a mimo to API odrzuca wywołanie
  • Końcówka „(or it may not exist)” sugeruje, że tożsamość może też wskazywać zły projekt lub ścieżkę

Przyczyna

Wywołanie predict jest operacją sprawdzaną przez IAM, a 403 oznacza, że uwierzytelniona tożsamość nie przechodzi tego sprawdzenia na tym zasobie.

  • Wołająca tożsamość nie ma roli. Wywołanie predict wymaga uprawnienia aiplatform.endpoints.predict, które niesie rola Vertex AI User (roles/aiplatform.user). Konto usługi utworzone dla aplikacji albo tożsamość CI/CD zwykle domyślnie go nie mają.
  • Zły projekt lub poświadczenia. Jeśli żądanie działa z Application Default Credentials dla innego projektu albo z kluczem złego konta usługi, tożsamość może po prostu nie istnieć na docelowym projekcie, co dokładnie opisuje końcówka „(or it may not exist)”.
  • Zła ścieżka zasobu. Pomyłka w projekcie, lokalizacji lub id endpointu daje odmowę na zasobie, na którym tożsamość nie ma nadania, i produkuje ten sam 403, nawet gdy wiązanie IAM jest poza tym poprawne.

Rozwiązanie

Krok 1: Zidentyfikuj wołającą tożsamość

Ustal dokładnie, jako która tożsamość uwierzytelnia się nieudane żądanie.

# Jaka tożsamość to bieżące poświadczenia?
gcloud auth list --format="value(account)"

# Jeśli aplikacja działa jako konto usługi, potwierdź które
# (np. na GKE przez Workload Identity, albo dołączone konto VM/Run)
gcloud run services describe YOUR_SERVICE --region=us-central1 \
  --format="value(spec.template.spec.serviceAccountName)" 2>/dev/null

Zanotuj adres e-mail tożsamości faktycznie wykonującej wywołanie, to podmiot, który potrzebuje nadania.

Krok 2: Nadaj rolę Vertex AI User

Zwiąż roles/aiplatform.user z tą tożsamością na projekcie, który jest właścicielem endpointu.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:your-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/aiplatform.user"

Wybierz tę predefiniowaną rolę zamiast ręcznie składać rolę własną. Niesie ona aiplatform.endpoints.predict plus powiązane uprawnienia odczytu, których wołający zwykle potrzebuje. Zmiany IAM mogą propagować się minutę lub dwie.

Krok 3: Potwierdź projekt i ścieżkę zasobu

Wyklucz przyczynę „zły projekt / zła ścieżka”, zanim uznasz, że IAM wciąż jest zepsute.

# Do jakiego projektu rozwiązują się bieżące poświadczenia?
gcloud config get-value project

# Czy endpoint faktycznie istnieje pod ścieżką z błędu?
gcloud ai endpoints describe ENDPOINT_ID --region=us-central1 \
  --project=PROJECT_ID --format="value(name)"
# Oczekiwane: pełna nazwa zasobu endpointu. Jeśli to zwraca 404,
# to Twoja ścieżka lub projekt jest zły, a nie IAM.

Upewnij się, że projekt, lokalizacja i id endpointu w Twoim kliencie dokładnie pasują do tej nazwy zasobu.

Krok 4: Zweryfikuj, że nadanie rozwiązuje uprawnienie

Sprawdź, że tożsamość ma teraz uprawnienie, bez uruchamiania pełnej predykcji.

# Podszyj się pod konto usługi i przetestuj uprawnienie
gcloud ai endpoints describe ENDPOINT_ID --region=us-central1 \
  --project=PROJECT_ID \
  --impersonate-service-account=your-sa@PROJECT_ID.iam.gserviceaccount.com
# Oczekiwane: endpoint opisuje się poprawnie pod tą tożsamością

Walidacja

Potwierdź, że prawdziwa predykcja kończy się teraz powodzeniem jako zamierzona tożsamość.

# Uruchom predykcję uwierzytelnioną jako konto usługi
gcloud ai endpoints predict ENDPOINT_ID --region=us-central1 \
  --project=PROJECT_ID \
  --json-request=request.json \
  --impersonate-service-account=your-sa@PROJECT_ID.iam.gserviceaccount.com
# Oczekiwane: ładunek predictions, bez 403

# Potwierdź, że wiązanie jest na miejscu
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.role=roles/aiplatform.user" \
  --format="value(bindings.members)" | grep your-sa
# Oczekiwane: konto usługi pojawia się

Nadaj roles/aiplatform.user konkretnemu kontu usługi, które woła endpoint, a nie szerokim grupom czy kontom użytkowników na skróty. Zbyt szerokie nadania na zasobach Vertex AI to częste ustalenie audytu, a zasada najmniejszych uprawnień jest tu bezpieczniejsza i prostsza w analizie.

 

Jerzy Kopaczewski

Zabezpieczasz dostęp do Vertex AI?

Umów bezpłatną rozmowę na 30 minut. Pomagamy zespołom projektować IAM o najmniejszych uprawnieniach dla Vertex AI, poprawnie podłączać konta usługi przez Workload Identity i trzymać dostęp gotowy na audyt.

Umów rozmowę

Powiązane