SAML 联合登录后限制特定用户通过控制台登录 EC2

在 AD + SAML 联合身份场景下，用户可能通过同一个高权限 IAM Role 登录 AWS 控制台。如果只想限制其中一部分用户不能使用 Session Manager 或 EC2 Instance Connect 登录实例，可以用 aws:userid 条件键做显式 Deny。

场景

客户环境中大量域用户通过 SAML AssumeRole 登录 AWS 控制台，使用的可能是 PowerUser 或 Administrator 这类高权限 Role。

出于合规要求，需要限制某些用户不能通过控制台进入 EC2 实例，主要涉及两类能力：

• SSM Session Manager：ssm:StartSession
• EC2 Instance Connect：ec2-instance-connect:SendSSHPublicKey

为什么不用 RoleSessionName

SAML 联合登录后，IAM 会生成会话标识。策略判断时更稳定可用的是全局条件键 aws:userid。它通常包含角色 ID 和会话名称，形式类似：

<role-id>:<session-name>

因为 role ID 部分会随 Role 变化，不适合硬编码，所以可以用通配符匹配会话后缀：

*:user-or-ou-id

示例策略

在目标 IAM Role 上增加一个显式 Deny：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyEC2LoginForSpecificFederatedUsers",
      "Effect": "Deny",
      "Action": [
        "ssm:StartSession",
        "ec2-instance-connect:SendSSHPublicKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:userid": [
            "*:<user-or-ou-id>"
          ]
        }
      }
    }
  ]
}

显式 Deny 优先级高于 Allow，所以即使 Role 里已有高权限策略，匹配条件的用户仍会被拦截。

验证方式

1. 使用目标 SAML 用户登录控制台。
2. 尝试通过 Session Manager 连接 EC2。
3. 尝试使用 EC2 Instance Connect。
4. 再用非受限用户验证不受影响。

如果 Deny 生效，目标用户会在调用相关 API 时被拒绝。

更推荐的长期方案

基于 aws:userid 硬编码用户后缀能快速解决问题，但维护成本高。更好的方式是从身份源层面拆分权限：

• 在 AD 中建立受限用户组，例如 AWS-No-EC2-Login。
• 在 IdP 中把不同用户组映射到不同 IAM Role。
• 创建专门的受限 Role，不授予 EC2 登录能力。

这样权限边界更清晰，也更容易审计和自动化管理。

总结

如果需要临时限制部分 SAML 用户通过控制台登录 EC2，可以用 aws:userid + 显式 Deny 精准拦截 ssm:StartSession 和 ec2-instance-connect:SendSSHPublicKey。

长期来看，建议把用户分组和 Role 映射放到身份源侧管理，而不是在一个高权限 Role 里维护越来越复杂的条件策略。