Назад | Перейти на главную страницу

Управление учетными данными безопасности IAM для нескольких контейнеров докеров

В простой среде EC2 управление доступом к другим ресурсам AWS довольно просто с помощью ролей и учетных данных IAM (автоматически извлекаемых из метаданных экземпляра). Еще проще с CloudFormation, где вы можете создавать роли на лету, когда вы назначаете конкретную роль приложения экземпляру.

Если бы я хотел перейти на Docker и выполнить своего рода развертывание M-to-N, где у меня есть M машин и N приложений, работающих на них, как мне следует ограничить доступ к ресурсам AWS для каждого приложения? Метаданные экземпляра доступны любому пользователю на хосте, поэтому у меня будет возможность видеть / изменять данные любого другого приложения в той же среде развертывания в каждом приложении.

Каковы наилучшие методы предоставления учетных данных безопасности контейнерам приложений, работающим в такой среде?

Есть такой проект: https://github.com/dump247/docker-ec2-metadata

Он действует как прокси для конечной точки метаданных экземпляра, возвращая роль, специфичную для контейнера. Я не использовал его раньше, но, похоже, он решает описываемый вами вариант использования.

Применение наименьших привилегий с использованием ролей и групп безопасности (даже если вы не упомянули о них) в AWS с EC2 - это лучшие практики для обеспечения безопасной среды для ваших приложений хостинга, особенно при использовании CloudFormation. Однако когда вы накладываете многопользовательскую среду Docker поверх нее, все начинает разваливаться.

Лучший ответ прямо сейчас, чтобы продолжать пользоваться преимуществами ролей, применяя наименьшие привилегии, - это не использовать мультитенантный подход. В основном используйте однозначное сопоставление между экземпляром EC2 и приложением, но вы все равно можете использовать кластеры / ASG. Docker по-прежнему является чрезвычайно полезным и мощным инструментом, который можно использовать для управления и развертывания приложений, но на данный момент роли применяются в экземпляре EC2, а не в контейнере. Это означает использование отдельных виртуальных машин для каждого приложения.

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

К сожалению, ни одно из этих решений не является очень желательным, и я ожидаю, что в будущем AWS решит эту конкретную проблему, в основном из-за растущей популярности контейнеров.