#amazon-web-services #amazon-dynamodb #aws-step-functions
#amazon-веб-сервисы #amazon-dynamodb #aws-пошаговые функции
Вопрос:
Просто интересно, сталкивался ли кто-нибудь со следующим вариантом использования:
- Учетная запись A имеет конечный автомат пошаговых функций
- Учетная запись B имеет таблицу DynamoDB
- Разрешить конечному автомату из учетной записи A помещать данные в таблицу DynamoDB в учетной записи B
Я знаю, что если мы используем Lambda с пошаговыми функциями, это допускает политики на основе ресурсов, и мы можем разрешить «Принципал» в Lambda в качестве конечного автомата arn из другой учетной записи и выполнить функцию lambda в учетной записи B из конечного автомата в учетной записи A.
Но DynamoDB не поддерживает политики на основе ресурсов, есть ли способ развернуть шаблон CloudFormation, в котором мы создаем таблицу DynamoDB с политикой / разрешением, которая позволяет использовать в ней конечный автомат из другой учетной записи?
Комментарии:
1. Не уверен насчет DynamoDB, но вот инструкции для доступа между учетными записями с помощью DynamoDB Accelerator (DAX): docs.aws.amazon.com/amazondynamodb/latest/developerguide /…
2. ну, вы всегда можете использовать Lambda для ввода данных в DynamoDB
3. К сожалению, эта проблема применима к нескольким сценариям. Служба должна быть осведомлена о «роли», то есть у нее должен быть параметр, указывающий, какую роль в другой учетной записи взять на себя, чтобы получить к ней доступ. Он не может угадать, какую роль использовать, какая роль может быть единственной. Я надеюсь, что специально для DynamoDB будет концепция, как для S3 и SNS, вместо политики темы / корзины было бы здорово иметь TablePolicyfor Dynamo! 🙂
4. в принципе, я думаю, вы можете попробовать перекрестные разрешения учетной записи между этими 2 учетными записями. Это означает, что вы попытаетесь предоставить разрешения перекрестного учета учетной записи A из B
Ответ №1:
Вы понимаете суть этого, но упускаете небольшой элемент, который делает это возможным.
Account A - contains:
Lambda that is part of a State Machine
Role A
Account B - Contains:
DynamoDb
Role B
Вы настроили лямбду с ролью A. Вы предоставляете Роли политику, чтобы принять роль B — вы не предоставляете Роли A никаких разрешений dynamo и не устанавливаете никаких разрешений на основе ресурсов в Dyanmo
Вы настраиваете роль B с возможностью быть принятым на себя Ролью A и с правами доступа DynamoDB.
Теперь вы можете взять на себя роль B, используя выбранный вами SDK (sts), и разрешить учетные данные безопасности, сохранить их и использовать для ваших вызовов DynamoDB sdk внутри вашего lambda в учетной записи A.
Это вполне возможно, но одним из основных недостатков является то, что вы должны быть довольно четкими с arn ролей разных учетных записей — и если одна сторона изменяет свои arn, система ломается. Безопаснее (и в некотором смысле лучше) настроить API с некоторыми базовыми операциями CRUD для Dynamo и попросить другую учетную запись вызвать его — если вы не пытаетесь сократить миллисекунды, этого, как правило, достаточно.