问题标签 [aws-policies]

我在这里问了一个非常相似的问题。我想在这个问题上增加更多的清晰度。

根据 AWS 文档，

NotPrincipal With Deny
当您在与“Effect”：“Deny”相同的策略语句中使用 NotPrincipal 时，策略语句中指定的操作将明确拒绝所有委托人，但指定的委托人除外。

和

当您使用 AWS 账户标识符作为策略中的委托人时，您将授权委托给该账户。

当帐户（根）ARN 包含在 Allow 语句的 Principal 元素中时，对帐户的委派有效。
相反，当帐户（根）ARN 包含在拒绝语句的 NotPrincipal 元素中时，对帐户的委派不起作用。

这让我想到 - 即使通过在 NotPrincipal 中排除 Account 根，Deny 也永远不能委托给 Account，即您仍然需要在策略的 NotPrincipal 元素中明确指定要从 Deny 中排除的各个 IAM 用户。此行为与只需要指定帐户（根）以进行进一步委派的 Allow 非常不同 - 无需明确指定哪些 IAM 用户应包含在 Allow 中。

问题：对帐户的授权是否仅适用于 Allow 语句？即，即使通过 NotPrincipal 元素排除了该帐户，假设对帐户的授权也不适用于 Deny 语句，这是否正确？

场景 1：允许仅使用帐户（根）ARN 的代表

下面的存储桶策略将让账户通过其 IAM 策略决定账户中的哪些 IAM 用户可以访问存储桶 - 委托有效。

场景 2：拒绝不仅使用帐户（根）ARN 进行委派

下面的存储桶策略不会让账户通过其 IAM 策略决定账户中的哪些 IAM 用户可以访问存储桶 - 委托不起作用。在 NotPrincipal 元素中指定帐户（根）ARN 不会委托。

总而言之，我试图找出以下陈述是否正确

委托给帐户（根）可以通过 Principal 和 NotPrincipal 元素实现，但委托本身仅适用于Effect:Allow。即使在 NotPrincipal 中排除了 Account (Root) 时，Account (Root) 的委派也不适用于Effect:Deny 。

我想创建 IAM 策略，其中 IAM 用户将无法在 us-east-1 区域中启动除 t2.micro Ubuntu 之外的任何实例。我在 IAM 策略中添加了 ami，但 AWS 不仅允许 Ubuntu ami，还允许 IAM 用户启动所有实例。可能是什么问题

}

我正在尝试使用 IAM 设置我的 CI/CD，只有特定的 IAM 用户才能使用Update我们的ProdCloudFormation 堆栈。

但我们Update对 CloudFormation 的政策如何运作感到困惑。

如果我的 IAM 用户只有一个策略：Update在ProdCloudFormation 堆栈上，即使他没有这些特定权限，他是否能够编辑/更改此堆栈中的任何资源？

例如，我在此堆栈上有一个 S3 存储桶，我在更新时更改了它的名称，即使他只有策略，该用户是否能够执行此操作Update？

我在账户 A 中设置了 API 网关，并且我已将账户 B 中的 lambda 与账户 A 中的 api 方法相关联（向账户 B 添加了正确的权限）。它过去总是完美地工作。

现在，当我尝试将更改部署到 api 网关时，它一直说“Lambda 函数的策略必须使用 SourceArn 条件显式授权方法或自定义授权方以进行跨账户集成”。

我已经检查了多次，所有权限都在 lambda 函数的帐户 B 中。我什至删除了它们并再次添加它们。如果我只为没有别名的 lambda 函数添​​加权限，它可以工作，但是当我添加我的别名时，我会收到"The policy of Lambda function must explicitly authorize the method or custom authorizer with a SourceArn condition for cross account integration"错误，但我可以在帐户 B 中看到我的 lambda 与别名的权限。

我究竟做错了什么？

有人可以就此提出建议吗？我正在尝试从 lambda 函数访问 S3 存储桶。我创建了以下策略：

但这似乎不起作用。我有一个假设角色策略：MalformedPolicyDocument：已禁止字段资源。

我们不能合并多个访问是同一个策略吗？

我已经建立了一个应用程序，它使用基于步进和简单扩展策略的自动扩展架构，使用消息 SQS 队列而不是负载均衡器。示例：如果队列上的可用消息为 10+，则从我的启动模板启动一个新实例，总共 2 个。同样，如果它们低于 10，简单扩展策略将运行实例的数量设置为等于 1 .

我注意到目标跟踪扩展策略是简单和步进扩展策略的更好替代方案。关于如何设置的任何想法/提示？

通过 SAM 部署 Lambda 后，当我尝试从 S3 下载时，我在 Lambda 中得到了 403。我在 IAM 管理控制台中检查了 Lambda 的角色，我看到角色只有AWSLambdaBasicExecutionRole. 但是，它还应该具有来自 SAM 模板的 S3 读/写策略。

这是我的 SAM 模板中的一个片段（部分内容已重命名）：

S3ReadPolicy 和 S3WritePolicy 不应该是 Lambda 角色的一部分吗？

有什么我想念的吗？

我知道我可以手动添加所需的策略，但显然我希望尽可能多地通过 SAM 自动发生。

其他细节：我不确定它是否重要，但为了附加上下文，Lambda 是 Step Function 状态机的一部分。我正在使用 boto3 库发出从 S3 下载的请求。我{'Code': '403', 'Message': 'Forbidden'}从 boto3 得到一个错误。

考虑为 accountA 中的 IAM 角色配置的以下信任关系：

这是否隐含地将访问范围缩小到在帐户 A 中运行的 cloudformation，或者任何其他帐户（B、C、D 等）中的 cloudformation 堆栈可以承担此角色？

我以前使用 sourceArn 条件来避免代理攻击，如下所示：

这是必要的，还是初始策略足以将信任关系缩小到 accountA？

我在尝试创建 Aurora 实例时收到此通知：

有谁知道kms:ListAliases属于哪个托管策略？在预制的管理策略中似乎找不到它。或者它可能不存在于托管策略中？

我有一个需要将消息发送到加密 SQS 队列的 AWS Lambda 函数。有一次，我的 AWS Lambda 函数可以向这个加密的 SQS 队列发送消息。在我开始工作后，我对权限进行了一些调整，使它们更加具体。然后，即使在我恢复到真正广泛的权限后，它也突然停止工作。

现在我总是收到以下错误：

我的 CMK 有以下政策，并且只允许：

我编辑了资源，但我三次检查了 ARN，它是正确的。

我的 Lambda 函数附加了以下策略：

这还不足以让我的 Lambda 向这个 SQS 队列发送消息吗？就像我在上面提到的那样，这比我试图限制我的 Lambda 上的策略更有效，然后即使在我将它改回来之后它也停止了工作。

我在这里想念什么？我不确定我还能改变什么以及为什么它起作用然后它停止工作......

编辑

似乎有效但现在无效的权限：

CMK 政策

Lambda 政策

编辑 2

必须有一些我不理解的东西在起作用，因为这无法预测......

我使用 CDK 进行了以下更改：

第一个变化：

结果：我可以再次向 SQS 队列发送消息

第二个变化：

结果：我不能再向 SQS 队列发送消息了？！？为什么？

第三个变化：

结果：我仍然无法向 SQS 队列发送消息？！？这里发生了什么？这是与第一次更改相同的策略状态....