上下文
我正在考虑将AWS Systems Manager Parameter Store用作我的分布式软件系统的系统级key:value商店。这将成为我整个系统在所有环境中的“规范秘密层”：本地/开发，CI / CD，登台，产品，保险库等...
因此，我显然需要确保对这些机密的访问受到限制。如果您在dev团队中，并且只需要访问本地开发环境所需的机密信息（例如，远程个人开发数据库的凭据），则无需访问prod层需要相同的秘密值（例如，远程产品DB的凭据）。
这是我卡住的地方
我刚刚开始使用AWS Systems Manager Parameter Store，我知道他们推荐organizing parameters into hierarchies，但是我对文档中有关使用getParametersByPath方法的警告感到非常困惑—这是我完全可以实现分层体系结构的唯一原因，因为如果愿意的话，您也可以简单地实现REDIS风格的“扁平”体系结构。
文档在很多地方大声地宣告：
警告
如果用户有权访问路径，则该用户可以访问所有路径 该路径的级别。例如，如果用户有权访问 路径/ a，那么用户也可以访问/ a / b。即使用户有 在IAM中明确拒绝访问参数/ a，他们仍然可以 递归调用GetParametersByPath API操作并查看/ a / b。
等等，那第一行又是什么？
那么有权访问/app/dev/ajb/*的用户也有权访问/app/dev/*吗？
等等，那最后一行又是什么？
为什么任何IAM用户/角色即使能够“ {拒绝访问” /a/b，也能够访问/a？
我上一次花了几天（也许很多）痛苦的日子来努力解决IAM策略，这是因为AWS IAM服务的默认设置为[strong]最低特权。这似乎与我过去从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
因此，dev用户ajb的IAM策略将限制开发人员对/app/dev/ajb/*的访问。
dev用户ava的IAM策略将限制开发人员对/app/dev/ava/*的访问。
并且prod Lambda角色的IAM策略会将对任何这些实例的访问限制为/app/prod/*。
问题
基于AWS文档的警告（如上所述），我的理解是，由于我必须授予对/app路径的访问权限才能授予对/app/dev/*的访问权限，这意味着对/app/dev/*路径的访问也将有权访问/app/prod/*路径上的任何值，因为IAM角色中的Resource值以/app路径开头？
警告中的最后一句话特别令人困惑：“即使用户在IAM中明确拒绝了对参数/ a的访问，他们仍然可以递归调用GetParametersByPath API操作并查看/ a / b。” 那么，基于此，任何用户都可以读取任何路径吗？
那么...即使我明确拒绝/app，只要任何用户都具有上游参数之一的IAM权限，任何用户都可以阅读/app/dev/*或/app/prod/*？
什么？？？有人可以帮助我理解这一点吗？