Файловое хранилище P12, что это такое

Обновлено: 03.07.2024

Сервисные аккаунты полезны для различных случаев использования GCP.

Сервисный аккаунт (электронная почта) аналогичен имени пользователя.

Если вы просто используете сервисный аккаунт в GCP, вам НЕ нужен ключ доступа (он известен GCP).
Если вы используете его для доступа к ресурсам GCP из-за пределов GCP, вам нужен способ аутентификации (своего рода пароль, соответствующий учетной записи службы). Этот пароль, который идет вместе с учетной записью службы, по сути является закрытым ключом (например, ключом p12 или ключом JSON). Ключ создается в консоли, чтобы GCP правильно связал его с сервисным аккаунтом.
Теперь, когда вы знаете, как пройти аутентификацию в GCP, важно различать два типа «паролей» (ключей доступа) — краткосрочные учетные данные и долгосрочные учетные данные.

Долговременные учетные данные сервисного аккаунта

Они представлены в виде файла ключа p12 или файла ключа JSON. В этом посте описывается, как создать эти учетные данные. После создания в GCP вам нужно будет сохранить их в соответствующем месте в вашей локальной среде, например. в доверенном магазине для вашего продукта, пытающегося получить доступ к ресурсу GCP.

В этом посте предполагается, что ресурс представляет собой Google Диск (те же инструкции для корзины облачного хранилища).

Кратковременные учетные данные сервисной учетной записи — это в основном аутентификация на основе токена OAuth или Open ID для любого ресурса GCP. Токен имеет ограниченный срок действия (и Open ID, и OAuth 2.0 имеют срок действия 3600 секунд – 1 час по умолчанию).

Создание долгосрочных паролей сервисных учетных записей (учетные данные в виде файла p12 или файла JSON)

Шаг 1. Добавьте учетные данные в проект (через меню IAM)

Какие учетные данные мне нужны?

Создайте ключ формата p12 (который будет использоваться в качестве пароля, соответствующего имени пользователя сервисного аккаунта)

Ключевой файл в формате p12 для работы с сервисным аккаунтом

Вот и все. Теперь у вас должен быть файл ключа p12 (его можно загрузить и добавить в локальные хранилища сертификатов, поскольку он действует как сертификат клиента).

Что вы делаете с этим ключом?

Этот ключ p12 служит сертификатом клиента (что-то вроде) и поэтому может быть добавлен в хранилище сертификатов на клиентском компьютере. Точно так же, как сертификат клиента используется для аутентификации клиентского ПК, этот ключ служит для аутентификации ПК в GCP (в частности, в проекте, с которым он был связан).

Что делать, если я хочу BYOK? (принесу свою пару ключей)

Да, это вполне возможно. Вы не обязаны использовать ключ, сгенерированный в Google Console. Вы можете загрузить общедоступную часть пары ключей и связать ее с проектом так же легко, как и в консоли.

Обзор

Все поставщики облачных услуг раскрывают концепцию сервисного аккаунта (роль в терминологии AWS). В GCP учетные записи служб используются повсеместно и служат для аутентификации вместо имени пользователя/пароля. Учетная запись службы (которая имеет формат адреса электронной почты) — имеет файл ключа p12 (который серверы в качестве связанного пароля). Сам файл ключа защищен выбранным пользователем паролем, поэтому, даже если он попадет не в те руки, файл ключа не имеет смысла без пароля к файлу ключа.

Используя эту комбинацию, можно обеспечить автоматический (от компьютера к компьютеру) доступ к корзинам облачного хранилища, дискам Google и любому ресурсу на основе API в GCP (который является КАЖДЫМ отдельным ресурсом в GCP). Счастливого Google Cloud!

Ануй имеет профессиональные сертификаты по Google Cloud, AWS, а также сертификаты по Docker и инструментам повышения производительности приложений, таким как New Relic. Он специализируется на облачной безопасности, шифровании данных и контейнерных технологиях.

Сервисные аккаунты полезны для различных случаев использования GCP.

Сервисный аккаунт (электронная почта) аналогичен имени пользователя.

Если вы просто используете сервисный аккаунт в GCP, вам НЕ нужен ключ доступа (он известен GCP).
Если вы используете его для доступа к ресурсам GCP из-за пределов GCP, вам нужен способ аутентификации (своего рода пароль, соответствующий учетной записи службы). Этот пароль, который идет вместе с учетной записью службы, по сути является закрытым ключом (например, ключом p12 или ключом JSON).Ключ создается в консоли, чтобы GCP правильно связал его с сервисным аккаунтом.
Теперь, когда вы знаете, как пройти аутентификацию в GCP, важно различать два типа «паролей» (ключей доступа) — краткосрочные учетные данные и долгосрочные учетные данные.

Долговременные учетные данные сервисного аккаунта

Создание долгосрочных паролей сервисных учетных записей (учетные данные в виде файла p12 или файла JSON)

Шаг 1. Добавьте учетные данные в проект (через меню IAM)

Какие учетные данные мне нужны?

Ключевой файл в формате p12 для работы с сервисным аккаунтом

Что вы делаете с этим ключом?

Что делать, если я хочу BYOK? (принесу свою пару ключей)

Обзор

Мы рекомендуем использовать закрытые ключи JSON (.json) для активации сервисных аккаунтов. Закрытые ключи JSON не требуют специальной криптографической библиотеки, описанной на этой странице. Чтобы создать новый закрытый ключ JSON для учетной записи службы, выполните действия, описанные в разделе Авторизация с помощью учетной записи службы. Инструкции по активации учетной записи службы с помощью интерфейса командной строки Google Cloud см. в статье gcloud auth activate-service-account. Остальная часть этой страницы неприменима, если вы используете закрытые ключи JSON.

Gcloud CLI позволяет разработчикам использовать закрытые ключи для аутентификации в учетных записях служб, также известных как учетные записи роботов. На этой странице описано, как создавать и использовать ключи p12 сервисных аккаунтов для Google Cloud.

Установите pyca/криптографию

Библиотека pyca/cryptography (версия >= 2.5) позволяет интерфейсу командной строки gcloud декодировать файлы ключей формата p12, которые идентифицируют учетную запись службы. Поскольку он включает в себя криптографические процедуры, pyca/cryptography не распространяется с интерфейсом командной строки gcloud.

Если в вашей системе установлен pip , интерфейс командной строки для индекса пакетов Python, для установки pyca/cryptography выполните следующую команду. Дополнительную информацию см. в инструкции по установке.

CLOUDSDK_PYTHON_SITEPACKAGES=1

После установки pyca/cryptography вам нужно будет установить для переменной среды CLOUDSDK_PYTHON_SITEPACKAGES значение 1 . Этот параметр переменной среды указывает интерфейсу командной строки gcloud, что он должен искать библиотеки за пределами своего собственного каталога google-cloud-sdk/lib. Как правило, установка CLOUDSDK_PYTHON_SITEPACKAGES=1 безопасна, но если что-то перестанет работать, вам может потребоваться отменить это действие.

Создание сервисного аккаунта

Чтобы создать новую учетную запись службы и загрузить файл ключа p12, выполните действия, описанные в разделе Создание ключей учетной записи службы.

Этот ключевой файл следует считать секретным, и вы должны принять меры предосторожности, чтобы убедиться, что он недоступен для ненадежных сторон. В unix-подобных системах вы можете сделать так, чтобы файл не был виден другим удаленно подключенным пользователям (кроме пользователя root), используя следующую команду.

Использование сервисного аккаунта с интерфейсом командной строки gcloud

Учетные данные служебной учетной записи можно активировать с помощью gcloud auth activate-service-account .

Чтобы использовать свою учетную запись службы с интерфейсом командной строки gcloud, запустите gcloud auth activ-service-account и передайте ему путь к файлу ключа с обязательным флагом --key-file и укажите учетную запись в качестве позиционного аргумента.

Используемый вами аккаунт должен совпадать с адресом электронной почты сервисного аккаунта, указанного в Google Cloud Console, но он не будет проверен; это только поможет вам вспомнить, какой аккаунт вы используете.

Теперь, когда учетная запись службы активирована, ее можно увидеть в списке учетных данных.

Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.

В App Engine мне нужен файл p12 для создания подписанных URL-адресов:

Google не описывает рекомендации по хранению этого файла.

Можно ли использовать каталог WEB-INF для хранения файла? Тогда он станет частью исходного кода и будет храниться вместе с паролем для его открытия.

Каковы здесь лучшие практики? Или другие подходы?

Как насчет производительности? Эффективно ли загружать файл снова и снова? Кэширует ли App Engine файл автоматически при вызовах (в одном и том же экземпляре)? Или мне нужно будет загрузить файл один раз с помощью сервлета, а затем каким-то образом сохранить его в статической переменной? Есть ли лучшие способы добиться этого, например сохранить файл в записи хранилища данных, а затем сохранить его в кэше памяти? Насколько безопасным будет такой подход? Наверное, ничего хорошего, верно?

Обычно я использую WEB-INF (недоступный из внешних источников) или путь к классам (папка классов, где хранятся скомпилированные java)

1 Ответ 1

В частности, в App Engine существует ряд необычных ограничений безопасности в отношении хранилища файлов. Я обнаружил, что лучшее место для безопасного хранения ресурсов — использование самого пакета. Если вы используете настройку Maven по умолчанию, созданную скелетным проектом appengine maven, это так же просто, как поместить файл в соответствующий каталог ресурсов

После того, как p12 окажется в правильном месте, вам нужно будет загрузить его с помощью функции GetResourceAsStream загрузчика классов. Затем при создании GoogleCredentials не используйте документированную функцию setServiceAccountPrivateKeyFromP12File(), а вместо этого используйте функцию setServiceAccountPrivateKey() и передайте только что созданный PrivateKey.

Кроме того, вы, скорее всего, не захотите использовать какую-либо из этих функций с работающим экземпляром appengine, поскольку Appengine уже предоставляет вам гораздо более простую в использовании функцию AppIdentityCredentials в этом случае, поэтому вам, вероятно, захочется определить, действительно ли ваше приложение находится в производственном режиме и использует ServiceAccount только при тестировании с использованием локального хоста.

Объединение всех этих функций дает следующую функцию, которая мне подходит:

Читайте также: