Проблема с разрешением GKE на gcr.io с учетной записью службы на основе terraform

У меня проблемы с получением контейнеров из gcr.io

$ kubectl get po
NAME                              READY   STATUS             RESTARTS   AGE
api-deployment-74d8cf8768-x8bsk   0/2     ImagePullBackOff   4          2m43s

Я создаю эти развертывания с помощью следующего файла yml (deployment.yml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: api
  template:
    metadata:
      labels:
        component: api
    spec:
      containers:
      - name: api
        image: eu.gcr.io/api:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 5060

из GKE - извлечение ErrImagePull из реестра контейнеров Google Я предполагаю, что это в основном проблема с разрешением.

If I do

kubectl describe pod api-deployment-74d8cf8768-x8bsk

я получил

rpc error: code = Unknown desc = Error response from daemon: pull access denied for eu.gcr.io/<project-dev>/api, repository does not exist or may require 'docker login': denied: Permission denied for "latest" from request "/v2/<project-dev>/api/manifests/latest"

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

Моя установка выглядит следующим образом. Я создал проект администрирования terraform в GCP (terraform-admin) с учетной записью службы

[email protected]

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

Compute Network Admin
Kubernetes Engine Cluster Admin
...

Затем я создаю свой фактический проект разработки project-dev (используя учетные данные этой служебной учетной записи). В project-dev [email protected] также является учетной записью iam в качестве

Owner
Compute Network Admin
Kubernetes Engine Cluster Admin

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

<project-dev-ID>[email protected]

которая является «учетной записью службы Compute Engine по умолчанию», которая, вероятно, не имеет соответствующих разрешений. В project-dev у меня также есть реестр контейнеров, содержащий мои частные контейнеры.

Как уже было сказано, я создаю свой кластер GKE с помощью Terraform. Ниже мой (сокращенный) yml-файл.

resource "google_container_cluster" "primary" {
  name     = "gke-cluster"
  location = "${var.region}-b"

  node_locations = [
    "${var.region}-c",
    "${var.region}-d",
  ]

  node_version       = var.node_version
  initial_node_count = 3
  network            = var.vpc_name
  subnetwork         = var.subnet_name

  addons_config {

    horizontal_pod_autoscaling {
      disabled = false
    }

  }

  master_auth {
    username = 'user'
    password = 'password'
  }

  node_config {

    # I HAVE TRIED ADDING THIS, BUT IT RESULT IN AN ERROR
    # Error: googleapi: Error 400: The user does not have access to service account 
    # service_account = "[email protected]"

    oauth_scopes = [
      "https://www.googleapis.com/auth/compute",
      "https://www.googleapis.com/auth/devstorage.read_only",
      "https://www.googleapis.com/auth/logging.write",
      "https://www.googleapis.com/auth/monitoring",
    ]

    labels = {
      env = var.gke_label["${terraform.workspace}"]
    }

    disk_size_gb = 10
    machine_type = var.gke_node_machine_type
    tags         = ["gke-node"]
  }
}

Теперь я должен попробовать (и если да, то как) добавить мою учетную запись службы tf-admin в качестве учетной записи службы в project-dev или мне следует добавить конкретную учетную запись службы (опять же, как?) В project-dev для kubernetes?


person Mike    schedule 01.05.2020    source источник


Ответы (1)


Вы можете использовать учетную запись службы вычислений по умолчанию <projectID>[email protected], у которой есть все необходимые разрешения для доступа к GCR. Просто убедитесь, что вы используете области по умолчанию для кластера или убедитесь, что области gcr включены вместе с разрешениями на чтение хранилища.

В качестве альтернативы вы можете использовать Terraform для создания учетной записи службы с достаточными разрешениями (например, роль наблюдателя хранилища), а затем назначить эту учетную запись службы пулу узлов. В этом случае вам нужно установить для oauth_scopes значение cloud_platform, чтобы области не мешали разрешениям IAM.

Вы можете просмотреть области GKE по умолчанию здесь

person Patrick W    schedule 01.05.2020
comment
Я не понимаю, что вы имеете в виду, используя учетную запись службы вычислений по умолчанию. Я вижу эту учетную запись службы, и в ней есть редактор ролей. Однако откуда мне знать, что используется то, что используется. Я отредактировал свой вопрос с более подробной информацией - person Mike; 01.05.2020
comment
вы не можете назначить учетную запись службы [email protected] кластеру в другой учетной записи. В вашем TF замените его на [email protected] - person Patrick W; 01.05.2020
comment
Здесь cloud.google.com/container-registry/docs/ Утверждается, что GKE по умолчанию может получить доступ к любому gcr.io в том же проекте. Похоже, что это не так. - person Mike; 01.05.2020
comment
да, по умолчанию, при условии, что он использует области действия по умолчанию и учетную запись службы по умолчанию. Использует ли ваш кластер учетную запись службы по умолчанию и области действия по умолчанию? - person Patrick W; 01.05.2020
comment
Я не знаю, но если я удалю сервис-аккаунт и oauth-scopes, должно быть, я думаю? Позвольте мне сначала попробовать это, а затем использовать учетную запись службы + настройку областей доступа oauth. - person Mike; 01.05.2020
comment
Если вы не знаете, какая SA является причиной ошибки, перейдите к ведению журнала и поиску, используя в качестве примера protoPayload.status.message = PERMISSION_DENIED. Это должно приблизить вас к виновнику - person dany L; 02.05.2020