Керування обліковими даними безпеки IAM для кількох контейнерів докера

У простому середовищі EC2 управління доступом до інших ресурсів AWS є досить простим з ролями та обліковими даними IAM (автоматично витягується з метаданих екземпляра). Ще простіше з CloudFormation, де ви можете створювати ролі на ходу, коли ви присвоюєте певну роль додатку екземпляру.

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

Які найкращі практики щодо надання облікових даних безпеки для контейнерів додатків, що працюють у таких умовах?

Є цей проект: https://github.com/dump247/docker-ec2-metadata

Він виступає проксі-сервером до кінцевої точки метаданих екземпляра, повертаючи роль, характерну для контейнера. Я раніше не використовував його, але, здається, вирішує випадок використання, який ви описуєте.

Застосування найменших пільг за допомогою ролей та груп безпеки (навіть якщо ви їх не згадували) в AWS з EC2 - це найкращі практики для забезпечення безпечного середовища для ваших хостингових додатків, особливо при використанні CloudFormation. Однак, коли ви накладаєте середовище Докера з багатьма орендарями, це означає, що все починає розвалюватися.

Найкраща відповідь зараз, щоб продовжувати отримувати переваги Ролей, застосовуючи при цьому найменшу пільгу, - це не використовувати підхід, який має багато орендарів. В основному використовуйте відображення "один на один" між екземпляром EC2 та додатком, але ви все одно можете використовувати кластери / ASG. Docker все ще є надзвичайно корисним і потужним інструментом, який можна використовувати для управління та розгортання ваших програм, але наразі ролі застосовуються в екземплярі EC2, а не контейнері. Це означає, що зараз використовувати окремі VM для кожної програми.

Якщо багатосторонній орендар важливіший за Ролі, то відповідь полягає в тому, щоб не використовувати Ролі та розповсюджувати облікові дані AWS у ваших програмах, використовуючи якийсь інший метод.

На жаль, жодне з цих рішень не є дуже бажаним, і я очікую, що AWS в майбутньому вирішить цю специфічну больову точку, в основному через зростаючу популярність контейнерів.