Пользовательская учетная запись для службы App Engine

Question

У меня есть несколько микро-сервисов, запущенных в GCP (Google Cloud Platform) нашего проекта. В нашем случае было бы предпочтительно минимизировать разрешения для каждой услуги. В настоящее время мы храним все файлы учетных данных в базе ключей, сохраняя секреты разделенными по составу команды. Поэтому, если я работаю над одним сервисом App Engine, я не вижу секретов для сервиса другого движка команды. То, что мы делали для других секретов, например, конфигурационных файлов с паролями и секретными токенами, мы даем привилегии для расшифровки KMS учетной записи службы механизма приложений и просто извлекаем зашифрованную копию файла конфигурации из хранилища и расшифровываем ее. Но мы не хотим везде использовать учетную запись службы движка приложений по умолчанию, потому что разные команды, использующие одну и ту же учетную запись службы, будут иметь доступ ко всем секретам. Поэтому мы хотим перейти на учетную запись службы для каждой службы в процессе разработки.

Из того, что я могу сказать в документации Google, они хотят, чтобы вы загрузили файл учетных данных (s) когда мы развертываем приложение, которое работает, однако, из облачной консоли, оказывается, что сложно определить, кто может просматривать файлы, развернутые в службе, и любой, у кого есть доступ, может просто скопировать / вставить все учетные данные.

Если у вас есть конфигурация в словаре, вы делаете что-то вроде этого:

from google.oauth2 import service_account
from google.cloud import kms_v1
d = {'type': 'service_account',
     'project_id': 'my-awesome-project',
     'private_key_id': '074139282fe9834ac23401',
     'private_key': '-----BEGIN PRIVATE KEY----\n supersecretkeythatnobodyknows==\n-----END PRIVATE KEY-----\n',
     'client_email': 'my-cool-address@my-awesome-project.iam.gserviceaccount.com',
     'client_id': '1234567890',
     'auth_uri': 'https://accounts.google.com/o/oauth2/auth',
     'token_uri': 'https://oauth2.googleapis.com/token',
     'auth_provider_x509_cert_url': 
     'https://www.googleapis.com/oauth2/v1/certs',
     'client_x509_cert_url': 'https://www.googleapis.com/robot/v1/metadata/x509/my-cool-addres%40my-awesome-project.iam.gserviceaccount.com'}

credentials = service_account.Credentials.from_service_account_info(d)
kms_client = kms_v1.KeyManagementServiceClient(credentials=credentials)

Это работает, но как мы можем получить словарь "d" в программу без его отображения вкод и иметь доступ к широкому кругу людей?

Answer 1

То, что Гийом Блэкьер сказал в своем ответе, верно, и я также согласен с его идеей иметь проект для каждой команды. Вы не можете создать отдельную учетную запись для каждой из служб вашего App Engine.

Хотя то, чего вы хотите достичь, может быть каким-то образом возможно в гибком App Engine. Итак, вы не можете найти способ разрешить только одну команду для одной службы и другую команду для другой. Что вы можете сделать (но я не думаю, что вы этого хотите, и я бы не советовал) блокировать определенные IP-адреса, контролируя ваш доступ через брандмауэры . Вы можете создавать свои собственные правила брандмауэра и разрешать запросы из одного места, а не из другого.

Это всего лишь прием, который может работать, а может и не работать. Настоящий совет заключается в том, что если вы действительно хотите внедрить описанную вами систему в чистоте и правильности с большим количеством учетных записей служб, вам следует рассмотреть возможность перехода на Cloud Run .

Answer 2

Если каждая служба в вашей среде AppEngine должна иметь свою собственную идентификацию, это невозможно с AppEngine. Новые сервисы, такие как Cloud Function или Cloud run, могут сделать это, но очень старый сервис (для облачной эры) AppEngine (более 10 лет) не может.

У вас есть сервисная учетная запись для всех сервисов AppEngine. Вы можете использовать его для расшифровки файла ключа учетной записи других служб для каждой службы и использовать их в соответствующей службе, но корневая авторизация остается стандартной учетной записью службы App Engine, и, таким образом, все службы / все группы могут иметь к ней доступ (и ко всемзашифрованные файлы ключей служебной учетной записи).

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