Ошибка разрешения при извлечении из gcr.io

Question

У меня есть 2 виртуальные машины, работающие на Google Compute Engine. Они идентичны, за исключением того факта, что они работают под разными учетными записями служб.
Обе эти учетные записи служб имеют (насколько я могу судить) одинаковые разрешения для сегментов, используемых gcr.io

Сценарий инициализации, запускаемый при запуске виртуальной машины, извлекает контейнер docker из gcr.io, на виртуальной машине, работающей под именем data-dev-dp@project-id.iam.gserviceaccount.com, pull успешно завершен:

Unable to find image 'gcr.io/project-id/gdp/jupyterlab-py2-spark-notebook:1.9' locally
1.9: Pulling from project-id/gdp/jupyterlab-py2-spark-notebook
bc51dd8edc1b: Pulling fs layer
b56e3f6802e3: Pulling fs layer

на виртуальной машине, работающей с data-dev-cmp@project-id.iam.gserviceaccount.com pull не выполняется:

Unable to find image 'gcr.io/project-id/gdp/jupyterlab-py2-spark-notebook:1.9' locally
/usr/bin/docker: Error response from daemon: pull access denied for gcr.io/project-id/gdp/jupyterlab-py2-spark-notebook, repository does not exist or may require 'docker login': denied: Permission denied for "1.9" from request "/v2/project-id/gdp/jupyterlab-py2-spark-notebook/manifests/1.9"

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

---

ОБНОВЛЕНИЕ. Я использовал набор инструментов (https://cloud.google.com/container-optimized-os/docs/how-to/toolbox), чтобы убедиться, что разрешения для корзины не совпадают для этих двух учетных записей:

# gsutil ls gs://artifacts.project-id.appspot.com
gs://artifacts.project-id.appspot.com/containers/

# gsutil ls gs://artifacts.project-id.appspot.com
AccessDeniedException: 403 data-dev-cmp@project-id.iam.gserviceaccount.com does not have storage.objects.list access to artifacts.project-id.appspot.com.

Очевидно, что это является причиной проблемы хотя мне очень странно, что мои скриншоты выше с консоли GCP предлагают другое. Я продолжаю расследование.

Answer 1

Это оказалось проблемой, которая нам всем слишком знакома, потому что мы постоянно создаем инфраструктуру, разрушаем ее и снова поддерживаем. При этом, особенно когда эти операции не выполняются чисто (как это было сегодня), мы можем оказаться в положении, когда роли назначаются старому экземпляру учетной записи службы. Консоль скажет вам, что учетной записи назначены роли, но на самом деле это не так. Мы часто сталкиваемся с этой проблемой.

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