GCP правильный способ доступа и хранения пароля / учетных данных через служебную учетную запись Compute Engine

Question

«Не встраивать секреты, связанные с аутентификацией, в исходный код» - часто можно услышать . Итак, я использую Службу управления ключами и Secret Manager .

Но тогда, как мне правильно получить доступ к секретам, хранящимся там из виртуальной машины Compute Engine и из моей локальной среды разработки?

Я могу подумать о:

1. Доступ к секретам с использованием учетных данных учетной записи службы по умолчанию , но как мне получить доступ к секретам в локальной среде разработки и внутри моих локальных Docker контейнеров (ie за пределами Compute Engine)?

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

   2.1. Сохраните его с исходным кодом, чтобы он был на компьютере разработчика и в контейнере Docker. Но тогда это идет вразрез с вступительным заявлением «Не вставляйте секреты ... в исходный код» . Плохая идея.

   2.2. Храните его где-нибудь на моей машине разработчика. Но тогда как мой Docker контейнер получает к нему доступ? Я мог бы предоставить ключ как Docker секрет, но разве это не было бы снова "встраиванием в исходный код" ? После запуска контейнера на моей виртуальной машине мне нужно было бы предоставить этот секрет откуда-то, и снова вернуться к вопросу о том, как секрет поступает на виртуальную машину.

I Знайте, что Учетные данные приложения по умолчанию (AD C) могут попытаться использовать вариант 2, а затем откатиться на вариант 1 - но как мне решить конфликт из варианта 2? Где должны находиться учетные данные учетной записи службы, чтобы они были доступны как для локального разработчика, так и для локального контейнера, а не для , встроенного в исходный код ?

Answer 1

Я нашел один способ сделать эту работу, ( sortof ):

• В локальной среде используйте GOOGLE_APPLICATION_CREDENTIALS для указания учетных данных учетной записи службы. загруженный вручную из GCP.

• В локальном контейнере Docker укажите тот же файл в качестве секретного. Затем мое приложение ищет его /run/secrets/, если GOOGLE_APPLICATION_CREDENTIALS не установлено.

• На виртуальной машине Compute Engine загрузите этот файл из корзины Google Storage (предварительно загрузив его). Учитывая, что используется учетная запись службы по умолчанию , если не указаны другие учетные данные, я могу gutils cp этот файл из корзины. Затем предоставьте этот загруженный файл в качестве секрета для контейнера.

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

Answer 2

Ваша идея с облачным хранилищем хороша и обходит ваши потребности; Самый простой способ получить доступ к секретам, хранящимся в Secret Manager из экземпляра виртуальной машины, будет с помощью curl, команды gcloud или сценария python с помощью «доступа к секретной версии» , а затем сохранить их как эфемерную переменную в коде. это предназначено для использования. Используемая служебная учетная запись может быть учетной записью службы по умолчанию CE, но имейте в виду, что она должна иметь роли secretmanager.secretAccessor и / или secretmanager.admin, чтобы иметь возможность получать их от SM. Дополнительно убедитесь, что экземпляр виртуальной машины имеет правильные области API для всех ресурсов GCP или, по крайней мере, для API безопасности.