AWS CLI Client.UnauthorizedOperation 即使设置了密钥答案

【问题标题】：AWS CLI Client.UnauthorizedOperation even when keys are setAWS CLI Client.UnauthorizedOperation 即使设置了密钥
【发布时间】：2015-03-29 03:14:37
【问题描述】：

我正在尝试设置 AWS CLI 工具，并按照http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/set-up-ec2-cli-linux.html#setting_up_ec2_command_linux 的说明进行操作

但是，在完成所有步骤并设置我的 AWS_ACCESS_KEY 和 AWS_SECRET_KEY 之后，我得到了

$ ec2-describe-regions
Client.UnauthorizedOperation: You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation; Request ID: 55f02cc4-2e9f-4a0a-8b55-46bcc1973f50)

然后我尝试重新生成新凭据，但仍然遇到相同的错误。我似乎无法找到有关其他人遇到此问题的信息。我尝试使用-O 和-W 传递密钥，但这也不起作用。

知道我做错了什么吗？

【问题讨论】：

标签： amazon-ec2 aws-cli

【解决方案1】：

某些策略必须分配给 IAM 用户和组，而不是 IAM 角色。我们将 AdministratorAccess 或 AmazonEC2FullAccess 等策略分配给为联合身份创建的 IAM 角色，但 AWS CLI 命令失败并返回相同的响应。

将策略分配给 IAM 用户和组可确保策略有效。我们将AmazonEC2FullAccess 等策略分配给管理员。对于列出区域和实例，正如describe-regions 命令所要求的那样，AmazonEC2ReadOnlyAccess 之类的策略就足够了，因为它们包含必要的语句以允许对所需资源进行受限操作。

【讨论】：

“必须将某些策略分配给 IAM 用户和组而不是 IAM 角色”的说法具有误导性。没有内在的需要这样做。如果您提供持久性 IAM 用户凭证，则附加到该 IAM 用户或该 IAM 用户组的 IAM 策略是相关的。如果您提供临时会话凭证（通过担任 IAM 角色从 STS 检索，这对于联合访问来说是典型的），那么附加到该 IAM 角色的 IAM 策略是相关的。
这是非常不准确的。策略可以附加到用户或组或角色，净效果应该或多或少相同（有一些在这里不适用的警告）

【解决方案2】：

我在免费套餐上，发现将管理员策略授予单个用户更容易，它支持从所有亚马逊命令行工具进行访问。如果您觉得政策过于宽松，您可以稍后将政策降级。

访问https://console.aws.amazon.com/iam/home
在左侧菜单中选择policies
根据亚马逊现有政策创建管理员政策
选择管理员复选框并附加到您的用户

假设您已设置访问密钥，您现在应该对给定用户拥有完整的命令行访问权限。

之前

› ec2-describe-regions
Client.UnauthorizedOperation: You are not authorized to perform this operation. (Service: AmazonEC2; Status Code: 403; Error Code: UnauthorizedOperation; Request ID: 3398ed18-1caf-4c04-865b-a54f796c653c)

之后

› ec2-describe-regions
REGION  eu-central-1    ec2.eu-central-1.amazonaws.com
REGION  sa-east-1   ec2.sa-east-1.amazonaws.com
REGION  ap-northeast-1  ec2.ap-northeast-1.amazonaws.com
REGION  eu-west-1   ec2.eu-west-1.amazonaws.com
REGION  us-east-1   ec2.us-east-1.amazonaws.com
REGION  us-west-1   ec2.us-west-1.amazonaws.com
REGION  us-west-2   ec2.us-west-2.amazonaws.com
REGION  ap-southeast-2  ec2.ap-southeast-2.amazonaws.com
REGION  ap-southeast-1  ec2.ap-southeast-1.amazonaws.com

亚马逊用户体验需要一些时间才能习惯

【讨论】：

我不敢相信你只是建议他们授予用户管理员权限来执行单个 ec2 操作。
@danielpops 我很高兴更新答案 - 你会推荐什么政策？我暗示该政策过于宽松，但我意识到大多数用户会忽略这一点，所以我很高兴整体改善答案。当我学习 AWS 时，这对我有用，但我也不想鼓励不良做法。
您应该推荐适当级别的权限来解决 OP 的访问问题，这仅允许单个操作 ec2:DescribeRegions，而不是您建议的访问 90 多个服务中的每个操作AWS 提供
@wislo 的答案（当前）是合适的，应该是公认的答案

【解决方案3】：

很遗憾，使用 EC2 CLI 工具的基本指南甚至没有提到这一点，但看起来我的问题是我的 IAM 账户下没有正确的策略设置。

{
"Version": "2012-10-17",
"Statement": [{
  "Effect": "Allow",
  "Action": "ec2:Describe*",
  "Resource": "*"
}]
}

查看此链接了解更多详情： http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html

【讨论】：

这真是可怜的恕我直言。由于这些问题，谷歌将超越 AWS。事情应该会奏效。实际上，一切仍处于测试阶段，对变化做出反应的成本很高。基于角色的策略非常好，但默认情况下保持打开状态，并警告我们。
@mckenzm 您是否建议默认安全策略应该是“允许所有访问所有内容”？那将是一个巨大的错误。谷歌云也不是这样做的——没有人这样做。必须明确授予权限。
至少对于 root 用户。默认情况下全部拒绝对于像 RACF 这样的东西来说非常好，在那里会有正式的管理，但对于默认/root 用户应该有一些“开箱即用”的访问权限，即使它在设置时是选择加入的。否则，如果它们不起作用，为什么还要有钥匙呢？
@mckenzm 实际上是 root 用户的默认设置。这就是您在设置初始 IAM 组和用户后应该禁用根用户凭证的原因。默认情况下，所有 IAM 凭证的权限为零，必须主动授予权限。