403 Запрещено в ESPv2, GKE AutoPilot, WIF

Я следую началу работы с конечными точками для GKE с ESPv2 . Я использую Workload Identity Federation и Autopilot в кластере GKE.

Я столкнулся с ошибкой:

F0110 03:46:24.304229 8 server.go:54] fail to initialize config manager: http call to GET https://servicemanagement.googleapis.com/v1/services/name:bookstore.endpoints.<project>.cloud.goog/rollouts?filter=status=SUCCESS returns not 200 OK: 403 Forbidden

Что в конечном итоге приводит к ошибке сбоя транспорта и отключению модуля.

Мой первый шаг состоял в том, чтобы исследовать проблемы с разрешениями, но я действительно мог бы использовать некоторые внешние взгляды на это, поскольку я ходил по этому кругу.

Вот моя конфигурация:

      >> gcloud container clusters describe $GKE_CLUSTER_NAME \
--zone=$GKE_CLUSTER_ZONE \
--format='value[delimiter="\n"](nodePools[].config.oauthScopes)'
      ['https://www.googleapis.com/auth/devstorage.read_only', 
'https://www.googleapis.com/auth/logging.write', 
'https://www.googleapis.com/auth/monitoring', 
'https://www.googleapis.com/auth/service.management.readonly', 
'https://www.googleapis.com/auth/servicecontrol', 
'https://www.googleapis.com/auth/trace.append']

      >> gcloud container clusters describe $GKE_CLUSTER_NAME \
--zone=$GKE_CLUSTER_ZONE \
--format='value[delimiter="\n"](nodePools[].config.serviceAccount)'
default
default

Имя учетной записи службы: test-espv2

Роли

      Cloud Trace Agent
Owner
Service Account Token Creator
Service Account User
Service Controller
Workload Identity User

Я связал svc-act WIF с кластером со следующим yaml

      apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: test-espv2@<project>.iam.gserviceaccount.com
  name: test-espv2
  namespace: eventing

И затем я связал стручок с test-espv2SVC-акт

      ---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: esp-grpc-bookstore
  namespace: eventing
spec:
  replicas: 1
  selector:
    matchLabels:
      app: esp-grpc-bookstore
  template:
    metadata:
      labels:
        app: esp-grpc-bookstore
    spec:
      serviceAccountName: test-espv2

Поскольку gcr.io/endpoints-release/endpoints-runtime:2ограничено, я создал тестовый контейнер и развернул его в том же eventingпространство имен.

В контейнере я могу получить конфигурацию службы конечной точки с помощью следующей команды:

      curl --fail -o "service.json" -H "Authorization: Bearer $(gcloud auth print-access-token)" \
 "https://servicemanagement.googleapis.com/v1/services/${SERVICE}/configs/${CONFIG_ID}?view=FULL" 

А также в контейнере я работаю как олицетворенная учетная запись службы, проверенная с помощью:

      curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/

Есть ли какие-либо другие тесты, которые я могу запустить, чтобы помочь мне отладить эту проблему?

Заранее спасибо,

2 ответа

Что касается отладки — я часто находил свои ошибки, следуя одному из других методов/языков программирования в учебниках Google.

Вы смотрели заметки OpenAPI и пытались следовать за ними?

Я наконец-то разобрался с проблемой. Он был в 2 частях.

  1. Повторное развертывание приложения с особым вниманием и проверкой kubectl annotate serviceaccountкоманды
    • add-iam-policy-binding для serviceController и cloudtrace.agent
    • опуская nodeSelector: iam.gke.io/gke-metadata-server-enabled: "true" из-за автопилота

Это позволило успешно развернуть kube, как показано в журналах.

Следующая ошибка у меня была

      <h1>Error: Server Error</h1>
<h2>The server encountered a temporary error and could not complete your request.<p>Please try again in 30 seconds.</h2>
  1. Это было исправлено, когда я снова обратил внимание на свой кластер Kube. Просматривая события в моей службе входа, поскольку я был в общем vpc, а мои политики безопасности разрешали управление брандмауэром только из основного проекта, при развертывании не удалось обновить правила брандмауэра.

Ручная подготовка их, как показано здесь:

https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#manually_provision_firewall_rules_from_the_host_project

решил мои проблемы.