为AWS用户配置权限时S3正常但SES、ElasticsearchService权限异常咨询

你之前的理解存在本质偏差：IAM权限模型的逻辑，从来不是“给子用户分配某服务的访问资格，就能让他看到和根账户完全一致的所有资源”。根账户是完全跳过所有IAM权限校验的特殊主体，子用户的资源可见范围，由IAM策略的Action范围、Resource范围、资源自身的访问策略、当前控制台选择的区域四个维度共同决定。你看到S3能全量展示桶，只是之前配的S3策略刚好满足了所有展示条件，不是S3的权限逻辑比其他服务特殊。

各问题的具体成因 #

为什么S3可以看到全量存储桶 #

你能看到所有桶，大概率是直接给用户附加了AmazonS3FullAccess这类AWS官方托管策略——这个策略的Resource范围直接配置为*，且包含了ListAllMyBuckets这类专门给控制台拉取桶列表用的Action，刚好满足控制台展示全量资源的条件，并不是S3的权限规则和其他服务有区别。

为什么配置SES权限后看不到全量已验证域名 #

SES控制台拉取已验证身份的逻辑，比你预期的权限要求多两个容易踩的坑：

• 权限范围配置不全：很多人写SES自定义策略时，会把Resource范围绑定到单个具体的域名/邮箱ARN上，但控制台拉取身份列表的动作（ses:ListIdentities）要求Resource范围为*才能正常返回全量列表。如果你把这个Action的资源范围锁死，哪怕对单个域名有操作权，控制台也会显示空列表。
• 区域匹配错误：SES是完全分区域部署的服务，你在根账户下验证的域名如果创建在美东1（us-east-1）区域，而子用户登录后控制台默认选了其他区域，哪怕权限配置正确，也看不到跨区域的SES资源。
• 容易漏看的前置校验：如果策略里额外配置了显式拒绝规则拦截了列表拉取动作，也会导致页面不显示已验证域名。

为什么OpenSearch（原Elasticsearch Service）的配置出现两种异常 #

这部分的两个现象分别对应不同原因：

1. 常规权限入口找不到服务：这是AWS IAM控制台的常见加载问题，不是权限不足。你在内联策略生成器里能搜到该服务，就说明服务本身在AWS的策略索引中存在，只是用户详情页的“附加现有策略”入口的服务列表加载不全，直接搜索服务全名就能正常定位到对应策略。
2. 加了内联策略还是看不到域：OpenSearch Service采用双重权限校验机制，只配IAM策略是不够的：
   • 第一层是IAM层面的列表权限：要在控制台看到域列表，必须给子用户开放es:ListDomainNames动作，且该动作的Resource范围要设为*。很多人配置时只给了具体域的操作权限，没有放开列表拉取的动作权限，自然看不到域列表。
   • 第二层是域自身的资源访问策略：每个OpenSearch域都有独立的访问控制策略，哪怕IAM层面权限全配通了，如果域本身的访问策略没有把该子用户的ARN加入允许列表，控制台也不会把这个域展示给子用户。

快速排查修复步骤 #

• 优先附加对应服务的官方全访问托管策略，排除自定义策略写错Action、Resource范围的问题：比如AmazonSESFullAccess、AmazonOpenSearchServiceFullAccess，这类策略是AWS预先配置好的，默认放开了所有控制台拉取列表需要的动作和资源范围。
• 对照根账户下资源创建的区域，把控制台切换到对应区域，不要用全局默认区域查看分区域部署的服务。
• 针对OpenSearch域，单独编辑域的访问策略，把目标子用户的ARN加入允许访问的主体列表。
• 排查完基础配置后，再根据最小权限原则逐步收紧策略的资源范围，不要一开始就锁死单个资源的权限，否则很容易触发控制台空列表的问题。

内容的提问来源于stack exchange，提问作者apiljic