У нас есть набор API в AWS, защищенных Cognito JWT.Аутентификация пользователей на основе их идентификаторов Cognito IdTokens и авторизация на основе пользовательских свойств Cognito прекрасно работает.
Некоторые из наших конечных точек API также называются «сервисными» процессами: запланированные процессы или задачи обслуживания, которые запускаются из функций Lambda ине связаны с каким-либо «реальным» пользователем.Нам нужны эти процессы, чтобы иметь возможность генерировать некоторый токен аутентификации / авторизации, который может быть проверен API.
Я рассмотрел:
- Создание реального'admin@example.com' Пользователь Cognito, сохраняющий пароль в Secrets Manager и аутентифицирующийся как этот пользователь в сервисных функциях .Не идеальный IMO, потому что он требует управления существованием объекта данных как части инфраструктуры, а также может быть точкой ограничения доступности.
- Генерация другого секретного токена для сервисных функций и специальныхВ случае его проверки в API .Не идеально, потому что теперь мы должны вручную поддерживать совместимость с сигнатурой Cognito JWT, а также изобретать колесо безопасности.Кроме того, мы должны либо делиться секретом между сервисными функциями и API, либо управлять парой ключей RSA.
Что я действительно хотел бы сделать, так это иметь какой-то способ для сервисных функций подписатьJWT основан на своих собственных учетных данных IAM, которые могут быть проверены в API путем вызова STS.Но я не хочу передать «реальный» набор учетных данных STS из сервисной функции (у которой есть разрешения на выполнение других действий, помимо простого вызова API).
Вкратце: как мне лучше «смешать» проверку пользователей Cognito и функций Lambda в одном API?