IBM Cloud: создание S3-совместимых кредитов для корзины через API
TL;DR Как мы можем автоматизировать создание учетных данных для каждого пользователя для доступа к сегментам COS, используя уровень совместимости S3?
Единственный документированный способ AFAIK - это CLI; но встраивание выполнения из командной строки в веб-службу не очень привлекательно!
В онлайн-документации IBM для COS (Cloud Object Storage) показано 2 способа создания "служебного ключа с учетными данными HMAC" для заданного сегмента и данной роли [ссылка]
- из пользовательского интерфейса администратора
- с помощью интерфейса командной строки >>
ibmcloud resource service-key-create ****** --parameters '{"HMAC":true}'
Смысл этих "кредитов HMAC" - получить доступ к корзине, как если бы она была сохранена в S3 (или любом другом устройстве, совместимом с S3 API).
Теперь я предполагаю, что и UI, и CLI используют какой-то скрытый API. Возможно, им придется жонглировать IAM API и COS API, чтобы выставить эту специфичную для COS функцию как "общую" функцию безопасности.
Но я не смог найти ничего подходящего в онлайн-документации для IAM API - единственный вызов API, который определяет "ресурс" и "политику авторизации", касается создания временного токена, а не постоянного ключа [ссылка],
я не мог " Не могу найти ничего подходящего и в COS API. Ничего о безопасности там нет.
И я бы попытался покопаться в исходном коде CLI, если бы он был с открытым исходным кодом, но, увы, это не так.
Я думаю, что моя единственная надежда - получить "внутреннюю информацию" от сотрудников IBM, которые на самом деле разработали CLI... отсюда и теги ниже.
0 ответов
Таким образом, когда вы создаете учетные данные службы с ключами HMAC, по сути, происходит то, что эти постоянные ключи генерируются COS (не IAM) и привязаны к идентификатору службы IAM (то есть пользователю, не являющемуся человеком). Когда вы отправляете запрос S3 API, создавая подпись с этими ключами, COS определяет связанный идентификатор службы и проверяет с помощью IAM, имеет ли этот идентификатор достаточные привилегии для запрашиваемой операции. Это позволяет вам использовать постоянные ключи HMAC за счет необходимости тратить часть ресурсов процессора на вычисление всего материала подписи HMAC для каждого запроса. Таким образом, в то время как IAM участвует за кулисами на уровне применения политик, аутентификация обрабатывается напрямую COS.
Теперь, если вы хотите программно создать учетные данные службы, для этого есть REST API, но нет опубликованных библиотек (хотя, я полагаю, вы могли бы попытаться создать их из спецификации OpenAPI). По сути, вы просто вызываете этот API и предоставляете
{"HMAC":true} немного внутри
"Parameters"объект. Внутри ответа вы найдете учетные данные с ключами HMAC.
При этом вы не хотите использовать токены IAM или подписи HMAC для конечных пользователей вашего приложения. Подумайте об идентификаторе службы, который вы связали с учетными данными HMAC, как об исполнителе выполняемых операций. Попытайтесь сохранить часть аутентификации пользователя изолированной, а затем, когда конечному пользователю разрешено что-то делать, пусть Service ID выполнит операцию. Очевидно, что все приложения будут разными и будут иметь свои проблемы. Один из использованных нами шаблонов (и я продолжаю собирать учебник для него) - это заставить приложение генерировать предварительно подписанный URL-адрес и передавать его клиенту, избегая необходимости передавать учетные данные за пределы области приложения..
По сути, IAM предназначен для администраторов, разработчиков и других облачных сервисов для аутентификации и авторизации действий в IBM Cloud (и, следовательно, не предназначен для масштабирования за пределы нескольких тысяч политик доступа), но вы должны искать что-то вроде App ID для частей authz конечного пользователя.
Какой язык / фреймворк вы используете? Вы используете COS SDK? Они абстрагируются от управления токенами, если вы предпочитаете использовать ключи API.