Я не эксперт в Elasticsearch, но, похоже, вы хотите безопасно переслать запрос от шлюза API в другой веб-сервис REST. Поскольку Elasticsearch является внешней веб-службой REST для AWS, у вас не будет доступа к ролям IAM. У меня была аналогичная интеграция с другой службой облачного отдыха (не эластичной поисковой системой), и я приложу все усилия, чтобы рассмотреть инструменты AWS, доступные для выполнения запроса.
Одна из идей - настроить запрос интеграции на ресурсе API Gateway, чтобы добавить заголовок авторизации с кредитами, созданными в ES. Это лучшая стратегия?
Это самая простая стратегия. В API Gateway вы можете отобразить пользовательские заголовки в запросе интеграции. Здесь вы сопоставите свой заголовок авторизации для Elastic Search.
Точно так же вы можете сопоставить свой заголовок авторизации как «переменную этапа», что облегчит обслуживание, если заголовок авторизации изменится в разных средах Elasticsearch.
В обеих стратегиях вы храните свой заголовок авторизации в API Gateway. Поскольку запрос к Elasticsearch должен быть HTTPS, данные будут в безопасности при передаче. Этот поток содержит дополнительную информацию о хранении учетных данных в API Gateway.
От MikeD @ AWS: В настоящее время нет известных проблем с использованием переменных этапа для управления учетными данными; однако переменные стадии не были специально разработаны, чтобы быть безопасным механизмом управления учетными данными. Как и вся информация о конфигурации API-шлюза, переменные этапа защищены стандартными разрешениями и политиками AWS и шифруются при передаче по проводам. Внутренне переменные этапа рассматриваются как конфиденциальная информация о клиенте.
Я думаю, что это относится к вашему вопросу. Вы можете сохранить заголовок авторизации в прокси-сервере шлюза API, однако вы должны признать, что информация о конфигурации шлюза API не была явно предназначена для конфиденциальной информации. При этом нет никаких известных проблем с этим. Этот подход наиболее прост в настройке, если вы готовы принять этот риск.
Что такое более подход "AWS"?
Подход "AWS" заключается в использовании сервисов, предназначенных для этой функции. Например, используя Службу управления ключами , чтобы сохранить свой заголовок авторизации Elasticsearch.
Аналогично учебнику , указанному в комментариях, вы захотите перенаправить свой запрос от API Gateway к Lambda. Вы будете нести ответственность за создание HTTPS-запроса к Elasticsearch на выбранном вами языке. Есть несколько руководств по этому вопросу, но это официальная документация AWS . AWS предоставляет чертежи в качестве шаблона для запуска лямбда-функции. Проект https-request будет работать.
Как только запрос пересылается из API-шлюза в Lambda, настройте заголовок авторизации для Lambda-запроса как Переменная среды и внедрите Шифрование переменной среды . Это безопасный рекомендуемый способ хранения конфиденциальных данных, таких как заголовок авторизации Elasticsearch.
Этот подход потребует дополнительной настройки, но использует службы AWS по назначению.
Мое мнение : Первоначально я использовал первый подход (заголовки авторизации в API Gateway) для аутентификации с помощью экземпляра dev, потому что это было быстро и легко, но, узнав больше, я решил, что второй подход был более согласовано с AWS Well Architected Framework