Использование оптимизированной для контейнеров ОС (COS) в Google Cloud Compute - лучшее способ доступа к учетным данным учетной записи службы по умолчанию для виртуальной машины -project из контейнера Docker?
$ gcloud compute instances create test-instance \
--image=cos-stable --image-project=cos-cloud
$ ssh (ip of the above)
# gcloud ...
Command not found
# docker run -ti google/cloud-sdk:alpine /bin/sh
# gcloud auth activate-service-account
... --key-file: Must be specified.
Если бы учетные данные были на виртуальной машине, Docker мог бы просто их смонтировать. Обычно учетные данные должны быть в .config/gcloud/, и сделать это с помощью docker run -v ~/.config/gcloud:~/.config/gcloud image. Неизвестно, доступны ли такие учетные данные в ОС контейнера и где, особенно потому, что они отсутствуют gcloud.
Если учетные данные не находятся на виртуальной машине и могут быть подключены, варианты, по-видимому, включают:
- Поместите учетные данные в метаданные контейнера / переменную среды;
- Create a
.jsoncredentials file for the service account, then- upload it to the VM, then mount it; or
- добавить
.jsonв контейнер;
- Запустите контейнер Docker (например, cloud-sdk-docker), который получает учетные данные и передает их. с хостами через, например, общий монтируемый раздел. В идеале это было бы с
gcloud auth activate-service-account
Есть ли канонический или рекомендуемый способ предоставить контейнеру Docker учетные данные учетной записи службы проекта виртуальной машины?
В Google Cloud уже есть желаемая модель политики безопасности: виртуальная машина внутри проекта должна иметь доступ, предоставляемый учетной записью службы. Чтобы избежать сложности и возможности неправильной конфигурации или сбоя, правильное решение будет использовать эту существующую модель безопасности, то есть не предполагающую создание, загрузку, распространение и поддержку файлов учетных данных.
Похоже, это будет обычная проблема, которую нужно будет решить с помощью COS, Docker и Kubernetes, поэтому я предполагаю, что упустил что-то прямое, но решение не было для меня очевидным из документации.
ИЗМЕНИТЬ. Обратите внимание на set-service-account API - этот вопрос можно свести к следующему:" Как вы используете API set-service-account с Контейнерной ОС? " Если это невозможно (из-за того, что в Контейнерной ОС отсутствуют gcloud и gsutil), я думаю, это следует отметить, чтобы пользователи ВМ могли планировать соответственно.
РЕДАКТИРОВАТЬ Чтобы следующие пользователи перечеркнули это:
Чтобы воспроизвести проблему, я использовал:
[local] $ ssh test-instance-ip
[test-instance] $ docker run -it gcr.io/google-appengine/python /bin/bash
[test-instance] $ pip install --upgrade google-cloud-datastore
[test-instance] $ python
>>> from google.cloud import datastore
>>> datastore_client = datastore.Client()
>>> q = datastore.query.Query(datastore_client, kind='MODEL-KIND')
>>> list(q.fetch())
[... results]
Проблема действительно заключалась в областях, заданных в API для экземпляра виртуальной машины, и, в частности, datastore API был отключен для учетной записи по умолчанию (под заголовком Области доступа к облачному API для ВМ). Можно найти области и необходимую datastore строку следующим образом:
> gcloud compute instances describe test-instance
...
serviceAccounts:
- email: *****[email protected]
scopes:
- https://www.googleapis.com/auth/datastore
...
...
Обратите внимание, что сама учетная запись службы имеет разрешение на хранилище данных (поэтому, как правило, к хранилищу данных можно получить доступ с помощью ключа учетных данных json для служебного ключа). Разрешения учетной записи службы были ограничены областями виртуальной машины.
