Доступ к учетным данным учетной записи службы Google Cloud в ОС контейнера внутри Docker Container

Question

Доступ к учетным данным учетной записи службы Google Cloud в ОС контейнера внутри Docker Container

Используя оптимизированную для контейнера ОС (COS) в Google Cloud Compute, как лучше всего получить доступ к учетным данным учетной записи службы по умолчанию для проекта VM из контейнера 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,

При отсутствии учетных данных, которые находятся на виртуальной машине и могут быть установлены, параметры могут включать:

Поместите учетные данные в метаданные контейнера / переменную среды;
Создать .json файл учетных данных для учетной записи службы, затем
1. загрузить его на виртуальную машину, затем смонтировать; или же
2. добавить .json в контейнер;
Запустите контейнер Docker (например, cloud-sdk-docker), который получает учетные данные и передает их хостам, например, через раздел общего монтирования. В идеале это было бы с gcloud auth activate-service-account

Есть ли канонический или передовой способ предоставления контейнера Docker учетными данными учетной записи службы проекта виртуальной машины?

У Google Cloud уже есть модель политики безопасности, желаемая: виртуальная машина внутри проекта должна иметь доступ, предоставляемый учетной записью службы. Чтобы избежать сложности и возможности неправильной конфигурации или неудачи, правильное решение будет использовать эту существующую модель безопасности, то есть не включать создание, загрузку, распространение и обслуживание файлов учетных данных.

Такое ощущение, что это будет обычная проблема, которую нужно будет решить с помощью COS, Docker и Kubernetes, поэтому я предполагаю, что упустил что-то прямое - но решение не было для меня очевидным из документации.

РЕДАКТИРОВАТЬ - Отмечая API set-service-account - этот вопрос может быть сокращен до "Как вы используете API set-service-account с Container OS?" Если это невозможно (потому что не хватает ОС контейнера) 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: *****-compute@developer.gserviceaccount.com
  scopes:
  - https://www.googleapis.com/auth/datastore
  ...
...

Обратите внимание, что сама учетная запись службы имеет разрешение на хранилище данных (поэтому к хранилищу данных можно получить доступ с помощью ключа доступа json для служебного ключа, как правило). Разрешения учетной записи службы были ограничены областями действия виртуальной машины.

30

google-cloud-platform google-compute-engine google-iam google-container-registry google-container-os

Источник

user19212 11 май '18 в 12:45

3 ответа

Решение

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

В случае ОС, оптимизированной для контейнеров, если виртуальная машина работает с учетной записью службы по умолчанию, она автоматически настраивается внутри контейнера cloud-sdk.

      user@instance-1 ~ $ docker run -it gcr.io/google.com/cloudsdktool/cloud-sdk:alpine /bin/bash
bash-5.1# gcloud config list
[component_manager]
disable_update_check = true
[core]
account = *************-compute@developer.gserviceaccount.com
disable_usage_reporting = true
project = my-project-id
[metrics]
environment = github_docker_image

Your active configuration is: [default]
bash-5.1# gcloud compute instances list
NAME        ZONE           MACHINE_TYPE  PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP  STATUS
instance-1  us-central1-a  e2-medium                  10.128.0.3   34.**.**.***  RUNNING

Следовательно, выполнять gcloud auth login и можно напрямую выполнить все gcloud при условии, что учетная запись службы по умолчанию имеет разрешения, а виртуальная машина явно включила конкретный API.

Однако этот вариант использования допустим, если виртуальная машина работает с no service account опция, выбранная при создании ВМ.

3

Источник

user7598188 07 мар '21 в 14:05

Я думаю, что это связано с конфигурацией вычислительного движка. DevopsTux уже сказал

      This is related to the instance scopes, 
not the service account permissions. 
Set the instance scope to "allow full access to all cloud APIs" 
and try again. Here is how: cloud.google.com/compute/docs/access/… – 

DevopsTux May 17, 2018 at 12:48

остановить экземпляр.
изменить области доступа, как показано ниже.

введите описание изображения здесь

0

Источник

user8854251 22 окт '22 в 23:52

Другие вопросы по тегам google-cloud-platform google-compute-engine google-iam google-container-registry google-container-os

user9176789 14 май '18 в 16:03 2018-05-14 16:03 · Accepted Answer · 2018-05-14 16:03

Обычный способ проверки подлинности будет отображаться в файле readme для SDK Google Cloud SDK.

Из экземпляра COS запустите это один раз:

docker run -ti --name gcloud-config google/cloud-sdk gcloud auth login

Это сохранит ваши учетные данные в gcloud-config Объем контейнера.

Этот том должен монтироваться только с контейнерами, к которым вы хотите иметь доступ к своим учетным данным, что, вероятно, не будет чем-то, что не cloud-sdk

docker run --rm -ti --volumes-from gcloud-config google/cloud-sdk:alpine gcloud compute instances create test-docker --project [PROJECT]  


Created [https://www.googleapis.com/compute/v1/projects/project/zones/us-east1-b/instances/test-docker].
NAME         ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP      STATUS
test-docker  us-east1-b  n1-standard-1               10.142.0.8   X.X.X.X  RUNNING

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

gcloud auth activ-service-account

Если вы хотите, чтобы gcloud (и другие инструменты Cloud SDK) использовали учетные данные учетной записи службы для отправки запросов, используйте эту команду, чтобы импортировать эти учетные данные из файла, содержащего закрытый ключ авторизации, и активировать их для использования в gcloud. Эта команда выполняет ту же функцию, что и gcloud auth login, но для использования служебной учетной записи, а не учетных данных пользователя Google.

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

В общем, Google рекомендует, чтобы каждый экземпляр, которому необходимо вызвать API Google, должен работать как учетная запись службы с минимальными разрешениями, необходимыми для этого экземпляра, чтобы выполнять свою работу. На практике это означает, что вы должны настроить учетные записи служб для своих экземпляров следующим образом:
1. Создайте новую учетную запись службы, а не используйте учетную запись службы Compute Engine по умолчанию.
2 - Предоставьте роли IAM этой учетной записи службы только для тех ресурсов, которые ей необходимы.
3 - Настройте экземпляр для запуска в качестве этой учетной записи службы.
4 - Предоставьте экземпляру область действия https://www.googleapis.com/auth/cloud-platform.
5. Избегайте предоставления большего доступа, чем необходимо, и регулярно проверяйте разрешения своей учетной записи службы, чтобы убедиться, что они актуальны.

ОБНОВИТЬ

Я не уверен, что set-service-account делает то, что вам нужно / нужно. С его помощью вы можете изменить учетную запись службы, которую использует экземпляр (хотя экземпляр должен быть остановлен, поэтому вы не можете использовать его, чтобы сменить учетную запись службы на изменение экземпляра). Однако вы можете использовать его как обычно для других случаев, смотрите:

jordim@cos ~ $ docker run --rm -ti --volumes-from gcloud-config google/cloud-sdk:alpine gcloud compute instances set-service-account instance-1 --service-account xx-compute@developer.gserviceaccount.com
Did you mean zone [us-east1-b] for instance: [instance-1] (Y/n)?  

Updated [https://www.googleapis.com/compute/v1/projects/XX/zones/us-east1-b/instances/instance-1].