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 для одного из вышестоящих параметров?
Что ??? Кто-нибудь еще может помочь мне разобраться в этом?