你们和我一样对 AWS 感到沮丧吗？(IAM - 明白了吗？它的双关语...
查看此IAM策略，该策略仅在几个月前，该策略100%有效且运行良好。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt123456",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": [
"arn:aws:lambda:ca-central-1:99999:function:test",
"arn:aws:lambda:us-east-1:99999:function:test",
"arn:aws:lambda:us-east-2:99999:function:test",
"arn:aws:lambda:us-west-1:99999:function:test",
"arn:aws:lambda:us-west-2:99999:function:test"
]
}
]
}
如果您今天将此2017 年有效策略粘贴到 IAM 控制台编辑器中，系统会告诉您：
此策略不授予任何权限。授予访问权限，策略 必须具有具有适用资源或条件的操作
现在，正如您自己所看到的，提供了5个非常具体的"适用资源"。那么这里给了什么呢？这些 AWS 男孩和女孩对我们现有的所有 IAM Lambda 策略做了什么？因此，我们仍然安全吗？
2018年的生活
因此，假设您刚刚创建了一个新的 Lambda fn，并且您希望授予单个用户权限，以便能够运行该特定 fn，而不能运行其他 fn。如果您从头开始并使用新的控制台，则可以有效地构建以下内容：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "*"
}
]
}
所以我们这里有一个大问题，不是吗？这个小星号意味着此策略可以在整个账户中运行任何 Lambda fn(我已经证明了这一点)。由于您无法再在权限 Lambda：InvokeFunction 中指定资源，因此此权限对于我们的用例毫无用处。
但是等等！还有另一个 Lambda 权限，称为 Lambda：Invoke，使用此权限，您可以在控制台编辑器中指定特定资源，如下所示：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "lambda:Invoke",
"Resource": "arn:aws:lambda:us-east-1:99999:function:test"
}
]
}
嗯，这看起来很不错，不是吗？！我的意思是，也许AWS只是将权限的名称从InvokeFunction更改为Invoke。哎呀，这还不错，当然不值得这个创纪录的长问题，对吧？呵呵，是的，好吧，不要像我做的那样，把所有的东西都引诱到你即将得分。欢迎来到这个新的地狱：
错误：用户：arn：aws：iam：：99999：user/PersistentDumbass 不是 授权执行： lambda：调用资源上的函数： ARN：AWS：Lambda：US-east-1：99999：函数：测试
什么？
好的，首先，我们没有在 AWS 开发工具包中调用一个名为"InvokeFunction"的函数，而是调用了"Invoke"。其次，我们确实将此策略附加到我们的用户。第三，我们等待了一个小时以确保这不是传播问题，并检查了相对无用的 AWS 服务运行状况控制面板 - 即使 us-east-1 关闭，该控制面板始终是绿色的。网飞。
所以神童们，我召唤你浏览AWS现在已经过时的文档和糟糕的命名选择，为我们应该允许一个用户调用一个特定函数的"当前方式"创建一个答案。
更新 1/8/2018
AWS 通过论坛向我发送了以下内容：
嗨，极客，
我们已在 IAM 控制台中将此识别为错误。我们正在工作 以解决此问题。 请继续使用 lambda：InvokeFunction 和 指定资源元素中的函数。您的初始保单 应该继续工作。请不要在 lambda：调用 政策。在 IAM 控制台中解决此问题后，我将更新您。
当亚马逊人使用他们的论坛时，这是美好的一天。但是，我仍将继续使用 AWS-CLI。
这个"答案"将像现在的AWS控制台一样100%混乱，而且没有办法绕过它。正如Michael - sqlbot在他的评论中回避的那样，他最近使用新的AWS Lambda控制台的体验不是很好，他想知道该策略是否正常，但控制台错误地将其报告为"未授予权限"。他是部分正确的。但问题更深。以下是我在"2018 Lambda IAM权限"中遇到的最好的刺痛，因为他们匆忙推出了一款不太出色的产品：
使用 AWS-CLI 创建策略;跳过蹩脚的控制台
- 在新文件夹中创建一个 policy.json 文件，其中包含您的策略
- 为您的 AWS-CLI 用户创建此策略：
{ "版本"： "2012-10-17"， "声明"：[ { "Sid"： "可视化编辑器0"， "效果"： "允许"， "操作"：[ "iam：CreatePolicy"， "iam：删除策略" ], "资源"："*" } ] }
- 从 AWS-CLI 运行以下命令：
AWS IAM 创建策略 --策略名称 myPolicyName --policy-document file://policy.json
注意一些陷阱
有一些微妙的差异会驱使你进行坚果测试。
- 即使文档会告诉您，在 Lambda fn 的 ARN 中添加"：version"或"：alias"是可以的，但不要这样做。只需以 fn 名称结尾即可。我还没有找到一种有效的方法来成功限制版本或别名。如果我的测试证明不是这样，我将更新此答案，但到目前为止，我可以通过在 ARN 中添加":P RODUCTION"来破坏良好的权限。
- 如果您是 AWS IAM 的老手，并且具有快速传播 IAM 策略的经验，例如在 10-15 秒范围内，那么那些日子似乎已经结束了。在第一次尝试之前等待整整 2 分钟，如果失败，再等待 2 分钟。自过去以来，事情已经大大放缓。
- 使用丢弃的名称测试策略，并在测试中放置版本号。考虑诸如"test-v1"，"test-v2"等名称，IAM似乎做了一些简短的缓存。如果您制定策略并且从不更改它，只需创建一个新版本，删除上一个测试的附件并附加下一个测试，则测试效果会更快。并等待 2 分钟。
- 接下来我将进行一些通配符测试;我想我在那个区域发现了更多的fubar，但我还没有测试过发布它。
这个有缺陷的控制台和不一致的文档花费了我 6+ 小时的努力。我希望这个问答能让你免于一些悲伤。