В настоящее время я работаю над проектом, который автоматически настроит новый проект Firebase / Gcloud. Он во многом полагается на интерфейс командной строки Firebase и gcloud SDK с учетными данными пользователя для нескольких обязательных шагов.
Сейчас я пытаюсь переместить этот проект в контейнер Docker в Cloud Run. Мне удалось аутентифицировать интерфейс командной строки Firebase с учетными данными пользователя, используя их встроенный токен CI-команда.
Я хотел бы спросить, можно ли аутентифицировать gcloud SDK аналогичным способом.
Почему сервисные аккаунты, вероятно, не будут работать
Я понимаю, что подобные программы обслуживания должны быть аутентифицированы с помощью учетных записей служб. В моем случае, однако, программа выглядит следующим образом:
- Используйте Firebase CLI для создания нового проекта gcloud / firebase
- Используйте gcloud SDK для добавления привязок IAM, включения API, биллинга и т. Д. Для нового проекта.
Я не могу использовать учетную запись службы для аутентификации запросов на шаге 2, так как проект только что был создан, и поэтому у меня еще не было возможности предоставить какой-либо учетной записи службы разрешение на его редактирование или загрузку файлов ключей. Вот почему я хотел бы аутентифицироваться с помощью токена, представляющего учетные данные пользователя.
По умолчанию среда Cloud Run фактически имеет доступ к учетной записи службы для проекта, в котором размещен контейнер. Поскольку у этой служебной учетной записи нет разрешения на редактирование вновь созданного проекта, использовать ее для аутентификации бессмысленно.
На данный момент есть идеи
gcloud auth login --no-launch-browser- требует взаимодействия с пользователем, и предоставленный ключ кажется уникальным для каждого сеанса входа в систему.- Поскольку интерфейс командной строки Firebase аутентифицируется с использованием учетных данных пользователя, может быть, есть способ использовать это для аутентификации gcloud SDK?
- Можно ли позволить учетной записи службы наследовать все разрешения пользователя? Я видел пару примеров этого, но они работают только на уровне проекта. Я понимаю, насколько неприличным было бы это решение.
- Кажется, что gcloud SDK сохраняет учетные данные пользователя в папке /root/.config/gcloud. Я пошел против всей разумной логики и скопировал эту папку при настройке своего Docker-контейнера. Это действительно работает, когда я запускаю его в локальном контейнере Docker, но когда я запускаю его в Cloud Run, учетная запись службы по умолчанию, кажется, переопределяет все другие учетные данные. Локальный контейнер Docker может получить доступ к скопированным конфигурациям, но даже если файлы скопированы успешно, gcloud SDK, похоже, не распознает их.
РЕДАКТИРОВАТЬ: Мои намерения состоят в том, чтобы позволить менее технически подкованным колледжам создавать новый проект Firebase с большим набором предопределенных настроек одним нажатием кнопки. Это включает в себя следующие шаги:
- Создайте новый проект Firebase (который автоматически создает новый проект Google Cloud)
- Включить биллинг
- Установите роли пользователей IAM и обновите / загрузите учетные записи служб
- Добавить Google Analytics
- Добавить облачное хранилище
- Создать новую корзину облачного хранилища
- Добавить собственный режим Firestore
- Скопируйте предварительно определенные облачные функции и роли безопасности и разверните их в облаке.
Созданный проект Google Cloud должен быть частью нашей организации Google Cloud. Владелец проекта не важен, так как я вручную устанавливаю роли IAM после создания.
Все вышеперечисленные шаги работают в моей локальной системе, и когда я использую идею №4, они также работают с общим контейнером докеров вне Cloud Run. Проблема, с которой я столкнулся, - это аутентификация запроса на шаге # 2 и шаг № 3. Поскольку оба этих запроса относятся к недавно созданному проекту, удостоверение службы по умолчанию для Cloud Run не может иметь необходимых ролей для аутентификации этих запросов в настоящее время. Вот почему я ищу способ аутентификации с использованием тех же учетных данных пользователя, которые использовались на шаге № 1 интерфейсом командной строки Firebase, поскольку эти учетные данные по умолчанию будут иметь права владельца.
