AWS Ограничения в управлении Cognito Group - PullRequest
Новая
       25

AWS Ограничения в управлении Cognito Group

0 голосов
/ 17 января 2020

Я пишу инструмент системного мониторинга, который будет периодически собирать метрики на заданных пользователем конечных точках с помощью Lambda, сохранять результаты в Dynamo, а затем разрешать пользователям получать метрики через приложение реагирования, которое будет вызывать другой экземпляр Lambda для извлечения данных из Динамо. В конечном итоге запросы будут выполняться к UID, назначенному каждому указанному пользователем монитору, который будет выполнять запрос через GSI datetime и monitorID.

Я искал Cognito, чтобы действовать в качестве моего хранилища пользователей. Моя цель - определить разрешения на уровне UID монитора, чтобы пользователи могли иметь доступ только к своему монитору. Я смотрю на создание группы для каждого монитора, которая затем будет назначена для создания пользователя. Затем группа будет включена в токен JWT, который Cognito предоставляет при входе в систему, который будет использоваться для авторизации вызова Lambda.

Мои вопросы:

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

Примечание : Основная причина, по которой я пришел к этой модели, заключается в том, что она не содержит состояний, имеет мелкую зернистость, не требует поиска разрешений для каждого запроса и не требует отдельного пользователя. записи для авторизации.

1 Ответ

0 голосов
/ 18 января 2020

Я не уверен, что это точно подойдет для вашего варианта использования, но очень чистое решение для мелкозернистого доступа - это использование политик доступа, основанных на дополнительном идентификаторе Cognito. Например, - это AWS do c для выполнения этого с префиксами S3 , чтобы имитировать файловую систему с пользовательскими каталогами. Например, 

{
    "Sid": "ListYourObjects",
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": ["arn:aws:s3:::bucket-name"],
    "Condition": {
        "StringLike": {
            "s3:prefix": ["cognito/application-name/${cognito-identity.amazonaws.com:sub}"]
        }
    }
},
{
    "Sid": "ReadWriteDeleteYourObjects",
    "Effect": "Allow",
    "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
    ],
    "Resource": [
        "arn:aws:s3:::bucket-name/cognito/application-name/${cognito-identity.amazonaws.com:sub}",
        "arn:aws:s3:::bucket-name/cognito/application-name/${cognito-identity.amazonaws.com:sub}/*"
    ]
}

Если вы знаете, что к монитору должен обращаться только один пользователь, и вы можете разрешить каждый монитор на основе вспомогательного идентификатора Cognito, это может быть самым чистым методом для вы.

...