Не удается отправить изображение в реестр контейнеров Google - у вызывающей стороны нет разрешения "storage.buckets.get"
Я работаю над конвейером bitbucket для отправки изображения в реестр контейнера gc. Я создал учетную запись службы с ролью администратора хранилища. (Bitbucket-authorization@mgcp-xxxx.iam.gserviceaccount.com)
gcloud auth activate-service-account --key-file key.json
gcloud config set project mgcp-xxxx
gcloud auth configure-docker --quiet
docker push eu.gcr.io/mgcp-xxxx/image-name
Несмотря на то, что вход в систему успешен, я получаю: Обмен токеном не удалось для проекта "mgcp-xxxx". Вызывающая сторона не имеет разрешения "storage.buckets.get". Чтобы настроить разрешения, следуйте инструкциям по адресу: https://cloud.google.com/container-registry/docs/access-control
Кто-нибудь может посоветовать, что мне не хватает?
Спасибо!
20 ответов
Для всех, кто читает здесь. Другие предложения здесь мне не помогли, однако я обнаружил, что также требуется роль учетной записи сборки облачной службы. Затемstorage.buckets.get исчезает.
Это моя минимальная установка роли (2) для отправки образов докеров:
Однако роль учетной записи сборки облачной службы добавляет гораздо больше разрешений, которые простоstorage.buckets.get. Точные разрешения можно найти здесь.
примечание: мне хорошо известно, что роль учетной записи сборки облачной службы также добавляетstorage.objects.getразрешение. Однако добавлениеroles/storage.objectViewerне решил мою проблему. Независимо от того, что у негоstorage.objects.get разрешение.
Если вышеуказанное не работает, возможно, у вас активна не та учетная запись. Это можно решить с помощью:
gcloud auth activate-service-account --key-file key.json
Если это не сработает, вам может потребоваться установить помощники учетных данных докера:
gcloud auth configure-docker --project <project_name>
И последнее замечание. Похоже, была некоторая задержка между установкой роли и ее работой черезgcloudинструмент. Однако это было минимально, подумайте о прицеле меньше минуты.
Ура
Вам необходимо войти в свою учетную запись и настроить проект на тот, который вам нужен. Есть большая вероятность, что вы просто не вошли в систему.
gcloud auth login
gcloud config set project <PROJECT_ID_HERE>
В прошлом у меня была другая учетная запись службы с тем же именем и другими разрешениями. После обнаружения того, что имена учетных записей служб кэшируются, я создал новую учетную запись службы с другим именем, и она работает корректно.
Это пошаговые команды, которые заставили меня отправить первый контейнер в закрытое хранилище GCE:
export PROJECT=pacific-shelter-218
export KEY_NAME=key-name1
export KEY_DISPLAY_NAME='My Key Name'
sudo gcloud iam service-accounts create ${KEY_NAME} --display-name ${KEY_DISPLAY_NAME}
sudo gcloud iam service-accounts list
sudo gcloud iam service-accounts keys create --iam-account ${KEY_NAME}@${PROJECT}.iam.gserviceaccount.com key.json
sudo gcloud projects add-iam-policy-binding ${PROJECT} --member serviceAccount:${KEY_NAME}@${PROJECT}.iam.gserviceaccount.com --role roles/storage.admin
sudo docker login -u _json_key -p "$(cat key.json)" https://gcr.io
sudo docker push gcr.io/pacific-shelter-218/mypcontainer:v2
Кажется, что документация устарела https://cloud.google.com/container-registry/docs/access-control
Примечание. Для отправки изображений требуются разрешения на чтение и запись объектов, а также разрешение storage.buckets.get. Роль администратора объекта хранилища не включает разрешение storage.buckets.get, но роль средства записи сегмента хранилища прежних версий включает.
Но
Storage Legacy Bucket Writer Роль больше не доступна.
Чтобы решить проблему с разрешениями, я добавил две роли в учетную запись службы.
- Администратор хранилища
- Средство просмотра объектов хранилища (у него есть разрешение storage.buckets.get)
Для всех, кто сталкивался с этим, моя проблема заключалась в том, что я не предоставил свой сервисный аккаунт Storage legacy bucket reader, Я только предоставил это Object viewer, Добавление этого прежнего разрешения исправило это.
Кажется, докер все еще использует устаревший метод для доступа к GCR
Здесь, в будущем, я обнаружил, что у меня больше нет вариантов Legacy. В этом случае я был вынужден предоставить администратора хранилища. Я открою запрос в Google по этому поводу, это немного чрезмерно, чтобы позволить мне выдвинуть изображение. Это может помочь кому-то еще из будущего.
Пробовал несколько вещей, но вроде надо запускать gcloud auth configure-docker
GCR просто использует GCS для хранения изображений, чтобы проверить разрешения для ваших артефактов. папка в GCS в рамках того же проекта.
После того, как меня очень раздражало то, что документы gcloud не охватывают стандартный вариант использования создания служебной учетной записи, которая может отправлять изображения на gcr.io, я решил сделать это:
Следующее предназначено для руководства (как руководство, оптимизированное для обучения) о том, как использовать автоматизацию копирования и вставки bash / zsh для создания учетной записи службы с нуля с правами извлечения изображения и правами отправки изображения на gcr.io.
Я превратил это в суть git для более удобного обмена:https://gist.github.com/neoakris/bd53146a7a610253abdbc1234ffb357b
См. здесь версию того же скоростного запуска: https://gist.github.com/neoakris/f1c4b329901811360ce6269ca631c80b
# Set Input Vars
export SA_SHORT_NAME=gcr-sa
export PROJECT=mygcpproject
export SA_NAME=$SA_SHORT_NAME@$PROJECT.iam.gserviceaccount.com
export SA_KEY_FILE=$HOME/Downloads/$SA_SHORT_NAME.auth.json
export TEST_IMAGE=gcr.io/$PROJECT/test
################################################################
# Prep work that will help make the full process easier to understand
# Login to your account with rights
gcloud auth login
# delete docker config for testability
mv $HOME/.docker/config.json $HOME/.docker/old-config.json
# Generate some test data
docker image pull busybox
docker image tag busybox "$TEST_IMAGE"1
docker image tag busybox "$TEST_IMAGE"2
docker image push "$TEST_IMAGE"1
# Unauthorized is expected, this is to improve testability
# Config docker as your admin user to upload test data
gcloud auth configure-docker
# Verify your human account can create an image
docker image push "$TEST_IMAGE"1
# delete docker config for testability
rm $HOME/.docker/config.json
################################################################
# Creating an SA with Image pull rights
# Create SA
gcloud iam service-accounts create $SA_SHORT_NAME --description="SA for GCR" --display-name="$SA_SHORT_NAME" --project=chrism-playground
# Create SA Auth Key in Downloads Folder
gcloud iam service-accounts keys create $SA_KEY_FILE --iam-account=$SA_NAME
# Add Image Pull rights
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$SA_NAME --role=roles/containerregistry.ServiceAgent
# Verify Rights
gcloud projects get-iam-policy $PROJECT \
--flatten="bindings[].members" \
--format='table(bindings.role)' \
--filter="bindings.members:$SA_NAME"
# Login as the SA
gcloud auth activate-service-account $SA_NAME --key-file=$SA_KEY_FILE
# Config docker as your SA user
gcloud auth configure-docker
# Verify that SA can pull from but not push to gcr.io
docker image pull "$TEST_IMAGE"1
# ^-- pull successful
docker image push "$TEST_IMAGE"2
# ^-- push complains about permissions
###################################################################
# Adding Image Push rights to SA
# Logout of all accounts (human and service accounts)
gcloud auth revoke --all
rm $HOME/.docker/config.json
docker image pull "$TEST_IMAGE"1
# ^-- fails, which verifies that this requires authentication
# Login as human to add image push rights to SA
gcloud auth login
# Alternative method of docker login as the SA:
# (It allows us to be logged in as SA from docker perspective, but logged
# in as human from gcloud perspective, which makes testing easier.)
cat $SA_KEY_FILE | docker login -u _json_key --password-stdin https://gcr.io
# Confirm that we have the same access as SA from docker perspective
# but admin access from gcloud perspective
docker image pull "$TEST_IMAGE"1
# ^-- pull successful (expected for SA)
docker image push "$TEST_IMAGE"2
# ^-- push complains about permissions (expected for SA)
gcloud projects get-iam-policy $PROJECT \
--flatten="bindings[].members" \
--format='table(bindings.role)' \
--filter="bindings.members:$SA_NAME"
# Shows the SA has roles/containerregistry.ServiceAgent
# ^-- this is an admin operation which shows gcloud is using human user rights
# Add Image Push rights
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$SA_NAME --role=roles/storage.admin
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$SA_NAME --role=roles/storage.objectViewer
# Test that SA has image push rights
docker image push "$TEST_IMAGE"2
# success
Метод пользовательского интерфейса:
- Добавить права на https://console.cloud.google.com/iam-admin/iam
- Роль — «Администратор хранилища», как описано в [1].
- Затем обновите свой токен с помощью:
gcloud auth login
gcloud config set project <PROJECT_ID_HERE>
- Нажмите еще раз
Ссылки, которые могут помочь:[1] https://cloud.google.com/storage/docs/access-control/iam-roles[2] https://cloud.google.com/container-registry/docs/access- контроль # грант
Добавить роль учетной записи службы
в облаке Google IAM
Editor
Storage object Admin
Storage object Viewer
исправить для меня
Я думаю, что несоответствие заключается в том, что https://cloud.google.com/container-registry/docs/access-control говорит, что во время#permissions_and_rolesраздел, в котором вам нужна роль администратора хранилища для отправки изображений. Однако в следующем разделе, в котором объясняется, как настроить доступ, говорится о добавлении администратора объекта хранилища, чтобы включить push-доступ для учетной записи, которую вы хотите настроить. Переключение на Storage Admin должно решить проблему.
В моем случае эта ошибка была вызвана тем, что Storage API (используемый для отправки образов Google Container Registry) был помещен внутри периметра службы VPC.
Это можно подтвердить и при необходимости диагностировать, просмотрев журналы, доступные на странице устранения неполадок VPC Service Controls .
Я создал отдельную учетную запись службы для обработки ввода-вывода GCR. Добавлена роль администратора реестра артефактов (мне нужно выталкивать и извлекать изображения), и он снова начал отправлять изображения в GCR.
Для отправки изображений требуются разрешения на чтение и запись объекта, а также разрешение storage.buckets.get. Роль администратора объекта хранилища не включает разрешение storage.buckets.get, но роль администратора хранилища устаревших сегментов включает. Вы можете найти это в примечании https://cloud.google.com/container-registry/docs/access-control.
docker push команда вернет эту ошибку разрешения, если докер не аутентифицирован с помощью grc.io
Следуйте инструкциям ниже.
Создайте учетную запись службы (или используйте существующую) и предоставьте следующие привилегии
- Администратор хранилища
- Администратор объекта хранения
Сгенерируйте ключ сервисной учетной записи (JSON) и загрузите его
Запустить
docker-credential-gcr configure-dockerВход в Docker со служебной учетной записью
docker login -u _json_key -p "$(cat [SERVICE_ACCOUNT_KEY.json])" https://gcr.ioПопробуйте запихнуть свой образ докеры в gcr
docker push gcr.io/<project_id>/<image>:<tag>
То, что сработало для меня, - это облачная консоль Google -> Я и администратор -> Настройка администратора хранилища в качестве одной из ролей для учетной записи службы.
Я потратил слишком много времени на выяснение этого, поскольку перенаправлял изображения из одного проекта в другой (намеренно) и не мог определить, к какой корзине мне нужно было предоставить доступ.
Подробности указаны на странице https://cloud.google.com/container-registry/docs/access-control.
Таким образом, чтобы нажать изображения с помощью Виртуальной сборки контейнера реестра вам необходимо предоставить для хранения устаревшего Bucket Writer для {проекта B -id}@cloudbuild.gserviceaccount.com учетной записи службы на {Накопитель-области} {артефакты проекта.. A - name}. сегмент .appspot.com .
Мне было трудно понять это.
Хотя сообщение об ошибке было таким же, моя проблема заключалась в том, что я использовал имя проекта, а не идентификатор проекта в URL-адресе изображения.