Context
Я думаю об использовании хранилища параметров AWS Systems Manager в качестве общесистемного хранилища key:value для моей распределенной программной системы. Это будет «слой канонических секретов» для всей моей системы во всех средах: локальный / dev, CI / CD, staging, prod, vault и т. Д.
Так что мне, очевидно, нужно убедиться, что доступ к этим секретам закрыт. Если вы работаете в команде dev и вам нужен только доступ к секретам, требуемым вашей локальной средой разработки (например, кредиты для вашей удаленной персональной базы данных разработчика), то вам не нужно иметь доступ к той же самой секретные значения, требуемые слоем prod (например, кредиты для удаленной БД продукта).
Вот где я застрял
Я только начинаю с Хранилище параметров AWS Systems Manager , и я знаю, что они рекомендуют организацию параметров в иерархии , но меня очень смущают предупреждения в документах в отношении использования метода getParametersByPath - единственной причины, которую я вижу для реализации иерархической архитектуры вообще, учитывая, что вы также можете просто реализовать REDIS-esque "плоскую" архитектуру, если хотите.
Документы объявляют громко и во многих местах:
Внимание
Если у пользователя есть доступ к пути, он может получить доступ ко всем
уровни этого пути. Например, если у пользователя есть разрешение на доступ
путь / а, то пользователь также может получить доступ к / а / б. Даже если у пользователя есть
Явно было отказано в доступе в IAM для параметра / а, они все еще могут
рекурсивно вызвать действие API GetParametersByPath и просмотреть /a/b.
Подождите, что это была за первая строка?
Таким образом, пользователь, имеющий доступ к /app/dev/ajb/*, также имеет доступ к /app/dev/*?
Подождите, что это была за последняя строка?
Почему любой пользователь / роль IAM сможет получить доступ к /a/b, даже если ему "явно отказано в доступе" к /a?
В прошлый раз, когда я провел пару (несколько, может быть, много) мучительных дней, борясь с политиками IAM, это было из-за наименьшего привилегированного по умолчанию сервиса AWS IAM - , который является превосходной архитектурой . Похоже, это полная противоположность того, к чему я привык в IAM, и это предложение секретной службы AWS. Что?
Это только я, или это похоже на недостаток в дизайне сделки, который я рассматриваю как свой "слой канонических секретов"!
Пример
Рассмотрим следующий пример, использующий формат /<app>/<env>/[user/]<key>:
/app/dev/ajb/DB_PATH = ajb-db.myapp.com
/app/dev/ajb/DB_USER = ajb
/app/dev/ajb/DB_PASS = 12345
/app/dev/ava/DB_PATH = ava-db.myapp.com
/app/dev/ava/DB_USER = ava
/app/dev/ava/DB_PASS = 54321
/app/prod/DB_PATH = db.myapp.com
/app/prod/DB_USER = prod-db-username
/app/prod/DB_PASS = JKLDFJDKLF@#@#7893728923
Таким образом, политика IAM для dev пользователя ajb будет ограничивать доступ разработчиков к /app/dev/ajb/*.
И политика IAM для dev пользователя ava будет ограничивать доступ разработчиков к /app/dev/ava/*.
И политика IAM для prod лямбда-роли ограничит доступ для любого из этих экземпляров /app/prod/*.
Вопросы
Основываясь на предупреждении из документов AWS (опубликованном выше), я понимаю, что, поскольку я должен предоставить доступ к пути /app, чтобы предоставить доступ к /app/dev/*, это означает, что любой сотрудник с доступом к * Путь 1101 * также будет иметь доступ к любому значению пути /app/prod/*, поскольку значение Resource в роли IAM начинается с пути /app?
Последнее предложение в предупреждении особенно сбивает с толку: "Даже если пользователю явно отказано в доступе в IAM для параметра / a, они все равно могут рекурсивно вызывать действие API GetParametersByPath и просматривать / a / b." Итак, исходя из этого, любой пользователь может прочитать любой путь?
Итак ... даже если я явно отрицаю /app, любой пользователь может прочитать /app/dev/* или /app/prod/*, если у него есть разрешения IAM для одного из вышестоящих параметров?
Что ??? Кто-нибудь еще может помочь мне разобраться в этом?