IAM 角色问题排查 - AWS Identity and Access Management
我无法代入角色我的 AWS 账户中出现新角色我无法编辑或删除我的 AWS 账户中的角色我无权执行：iam:PassRole为什么我无法在 12 小时会话中代入角色？（AWS CLI、AWS API）当我尝试在 IAM 控制台中切换角色时收到错误 我的角色具有一个允许我执行操作的策略，但出现“访问被拒绝”错误服务未创建角色的默认策略版本
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅中国的 AWS 服务入门。

IAM 角色问题排查

使用此处的信息可帮助您诊断和修复在使用 IAM 角色时可能遇到的常见问题。

我无法代入角色

请检查以下事项：

  • 确保使用角色的确切名称，因为角色名称区分大小写。

  • 验证您的 IAM 策略是否向您授予为要担任的角色调用 sts:AssumeRole 的权限。您的 IAM 策略的 Action 元素必须允许您调用 AssumeRole 操作。此外，您的 IAM 策略的 Resource 元素必须指定您要带入的角色。例如，Resource 元素可以按其 Amazon 资源名称 (ARN) 或按通配符 (*) 指定角色。例如，至少一个适用于您的策略必须授予与以下权限类似的权限： 

        "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws-cn:iam::account_id_number:role/role-name-you-want-to-assume"

  • 验证您的 IAM 身份是否标记有 IAM 策略需要的任何标签。例如，在以下策略权限中，Condition 元素要求您（因为委托人请求担任该角色）必须具有特定标签。您必须被标记有 department = HR 或 department = CS。否则，您无法担任该角色。要了解如何标记 IAM 用户和角色，请参阅标记 IAM 用户和角色。 

        "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "*",
    "Condition": {"StringEquals": {"aws:PrincipalTag/department": [
            "HR",
            "CS"
        ]}}

  • 确保您满足角色的信任策略中指定的所有条件。Condition 可以指定有效期、外部 ID 或请求必须来自于特定 IP 地址。请考虑以下示例：如果当前日期是指定日期以后的任意时间，则策略根本不会匹配，并且无法为您授予担任该角色的权限。 

        "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws-cn:iam::account_id_number:role/role-name-you-want-to-assume"
    "Condition": {
        "DateLessThan" : {
            "aws:CurrentTime" : "2016-05-01T12:00:00Z"
        }
    }

  • 验证您用于调用 AssumeRole 的 AWS 账户是否为您要担任的角色的受信任实体。在角色的信任策略中将受信任实体定义为 Principal。以下示例是一个信任策略，它附加到您要担任的角色。在该示例中，您登录时使用的 IAM 用户的账户 ID 必须是 123456789012。如果您的账号未在角色信任策略的 Principal 元素中列出，则无法担任该角色。在访问策略中为您授予何种权限无关紧要。注意，示例策略将权限限制为在 2017 年 7 月 1 日至 2017 年 12 月 31 日 (UTC 时间，这两个日期也包含在内) 之间发生的操作。如果您在上述日期范围之前或之后登录，则策略不匹配，您无法担任该角色。 

        "Effect": "Allow",
    "Principal": { "AWS": "arn:aws-cn:iam::123456789012:root" },
    "Action": "sts:AssumeRole",
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2017-07-01T00:00:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2017-12-31T23:59:59Z"}
    }

我的 AWS 账户中出现新角色

某些 AWS 服务要求您使用直接与该服务相链接的唯一服务角色类型。该服务相关角色由服务预定义，具有服务所需的所有权限。这样您就不必手动添加必要的权限，从而能够更轻松地设置服务。有关服务相关角色的一般信息，请参阅使用服务相关角色。

在开始支持服务相关角色时，您可能已在使用服务。如果事实如此，您可能会收到一封电子邮件，告知您账户中将有新角色。该角色包括此项服务代表您执行操作所需的所有权限。您不需要执行任何操作支持该角色。但是，您不能从账户中删除该角色。这样会删除此项服务访问 AWS 资源所需的权限。您可以转至 IAM 控制台的 IAM 角色页面来查看您的账户中的服务相关角色。服务相关角色在表的 Trusted entities 列中随 (Service-linked role) 一起显示。

有关哪些服务支持服务相关角色的信息，请参阅使用 IAM 的 AWS 服务并查找服务相关角色列为是的服务。有关使用某个服务的服务相关角色的信息，请选择 Yes 链接。

我无法编辑或删除我的 AWS 账户中的角色

您不能删除或编辑 IAM 中的服务相关角色的权限。这些角色包括服务代表您执行操作所需的预定义信任和权限。您可以使用 IAM 控制台、AWS CLI 或 API 仅编辑服务相关角色的描述。您可以转至控制台中的 IAM Roles (角色) 页面来查看您的账户中的服务相关角色。服务相关角色在表的 Trusted entities 列中随 (Service-linked role) 一起显示。角色的 Summary 页面上的横幅也指示角色是服务相关角色。您只能通过链接的服务管理和删除这些角色 (如果该服务支持此操作)。修改或删除服务相关角色时要小心，因为这样做可能会删除服务访问 AWS 资源所需的权限。

有关哪些服务支持服务相关角色的信息，请参阅使用 IAM 的 AWS 服务并查找服务相关角色列为是的服务。

我无权执行：iam:PassRole

在创建服务相关角色时，您必须有权将该角色传递给服务。在某些服务中执行操作时，该服务自动在您的账户中创建一个服务相关角色。例如，在首次创建 Auto Scaling 组时，Amazon EC2 Auto Scaling 为您创建 AWSServiceRoleForAutoScaling 服务相关角色。如果您尝试创建 Auto Scaling 组而没有 PassRole 权限，则会出现以下错误：

ClientError: An error occurred (AccessDenied) when calling the PutLifecycleHook operation: User: arn:aws:sts::111122223333:assumed-role/Testrole/Diego is not authorized to perform: iam:PassRole on resource: arn:aws:iam::111122223333:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling

要纠正该错误，请要求管理员为您添加 iam:PassRole 权限。

要了解哪些服务支持服务相关角色，请参阅使用 IAM 的 AWS 服务。要了解服务是否自动为您创建服务相关角色，请选择是链接以查看服务的服务相关角色文档。

为什么我无法在 12 小时会话中代入角色？（AWS CLI、AWS API）

在使用 AWS STS AssumeRole* API 或 assume-role* CLI 操作担任角色时，您可以为 DurationSeconds 参数指定一个值。您可以指定 900 秒（15 分钟）到角色的最大会话持续时间设置之间的值。如果指定的值高于该设置，操作将失败。该设置的最大值为 12 小时。例如，如果您指定的会话持续时间为 12 小时，但管理员设置的最大会话持续时间为 6 小时，您的操作将失败。要了解如何查看您的角色的最大值，请参阅查看角色的最大会话持续时间设置。

如果您使用角色链 (使用一个角色担任另一个角色)，您的会话限制为最多 1 小时。如果您随后使用 DurationSeconds 参数提供大于 1 小时的值，操作将失败。

当我尝试在 IAM 控制台中切换角色时收到错误

您在切换角色页上输入的信息必须与角色的信息匹配。否则，操作失败，您会收到以下错误：

Invalid information in one or more fields. Check your information or contact your administrator.

如果您收到此错误，请确认以下信息是否正确：

  • 账户 ID 或别名 – AWS 账户 ID 是 12 位数字。您的账户可能有一个别名，这是一个友好的标识符，例如您的公司名称，可用来代替您的 AWS 账户 ID。您可以在此字段中使用账户 ID 或别名。

  • 角色名称 – 角色名称区分大小写。账户 ID 和角色名称必须与为角色配置的内容匹配。

如果您继续收到错误消息，请与您的管理员联系以验证以前的信息。角色信任策略或 IAM 用户策略可能会限制您的访问权限。您的管理员可以验证这些策略的权限。

我的角色具有一个允许我执行操作的策略，但出现“访问被拒绝”错误

您的角色会话可能受会话策略的限制。以编程方式使用 AWS STS 请求临时安全凭证时，您可以选择传递内联或托管会话策略。会话策略是高级策略，在以编程方式为角色创建临时凭证会话时，这些策略将作为参数进行传递。您可以使用 Policy 参数传递单个 JSON 内联会话策略文档。您可以使用 PolicyArns 参数指定最多 10 个托管会话策略。生成的会话的权限是角色的基于身份的策略与会话策略的交集。或者，如果您的管理员或自定义程序为您提供临时凭证，它们可能已包含会话策略以限制您的访问。

服务未创建角色的默认策略版本

服务角色是服务代表您在您的账户中执行操作而担任的角色。在设置一些 AWS 服务环境时，您必须为服务定义要代入的角色。在某些情况下，服务会在 IAM 中为您创建服务角色及其策略。尽管您可以从 IAM 内部修改或删除服务角色及其策略，但 AWS 不建议这样做。角色和策略仅供该服务使用。如果编辑策略并设置另一个环境，则当服务尝试使用相同的角色和策略时，操作可能会失败。

例如，首次使用 AWS CodeBuild 时，服务会创建一个名为 codebuild-RWBCore-service-role 的角色。该服务角色使用名为 codebuild-RWBCore-managed-policy 的策略。如果编辑策略，它会创建一个新版本并将该版本保存为默认版本。如果您在 AWS CodeBuild 中执行后续操作，服务可能会尝试更新策略。如果是这样，您会收到以下错误： 

codebuild.amazon.com did not create the default version (V2) of the codebuild-RWBCore-managed-policy policy that is attached to the codebuild-RWBCore-service-role role. To continue, detach the policy from any other identities and then delete the policy and the role.

如果您收到此错误，则必须在 IAM 中进行更改，然后才能继续服务操作。首先，将默认策略版本设置为 V1，然后重试该操作。如果先前删除了 V1，或者如果选择 V1 不起作用，则清理并删除现有策略和角色。

有关编辑托管策略的更多信息，请参阅编辑客户托管策略（控制台）。有关策略版本的更多信息，请参阅IAM 策略版本控制。

删除服务角色及其策略

  1. 登录 AWS 管理控制台 并通过以下网址打开 IAM 控制台 https://console.amazonaws.cn/iam/。

  2. 在导航窗格中，选择 Policies。

  3. 在策略列表中，选择要删除的策略的名称。

  4. 选择策略使用情况选项卡，以查看哪些 IAM 用户、组或角色使用此策略。如果这些身份中的任何一个使用此策略，请完成以下任务：

    1. 创建具有必要权限的新托管策略。要确保这些身份在操作之前和之后具有相同的权限，请从现有策略中复制 JSON 策略文档。然后创建新的托管策略并粘贴 JSON 文档，如 JSON 选项卡上的创建策略中所述。

    2. 对于每个受影响的身份，附加新策略，然后分离旧策略。有关更多信息，请参阅 添加和删除 IAM 身份权限。

  5. 在导航窗格中，选择 Roles。

  6. 在角色列表中，选择要删除的角色的名称。

  7. 选择信任关系选项卡以查看哪些实体可以代入该角色。如果列出了服务以外的任何实体，请完成以下任务：

    1. 创建信任这些实体的新角色。

    2. 您在上一步中创建的策略。如果跳过了该步骤，请立即创建新的托管策略。

    3. 通知代入该角色的任何人，他们不能再这样做。向他们提供有关如何代入新角色并具有相同权限的信息。

  8. 删除策略。

  9. 删除角色。