CI/CD 管道的 IAM 权限

sta*_*ang 7 amazon-web-services amazon-iam

我想设置我的部署管道,以便它们在将​​资产部署到 AWS 时遵守最低权限原则。这意味着我不想授予部署策略管理员访问权限或“*:*”权限。

问题是,每次创建新管道时,我都必须经过反复试验的过程:

  • 部署
  • 由于缺少 IAM 权限而失败
  • 更新 IAM 政策以添加缺少的权限
  • 重复

我已经搜索了资源来帮助解决这个问题,但一般的方法似乎是过度配置 IAM 策略,我认为这是一种非常糟糕的方法。

您是否可以使用任何工具来分析 CloudFormation 模板并生成所需部署策略的 JSON 文档?(或无服务器框架或 CDK?)

Aar*_*erg 5

很好的问题,不幸的是,答案有点棘手。

对于所有基础设施即代码提供程序(无服务器、CDK、CloudFormation、Terraform 等),您都遇到了一些鸡与蛋的问题。

请记住,该IAM用户部署应用程序是不一样的IAM角色,你的应用程序(拉姆达)运行下。

这意味着,如果您想严格限制部署用户的权限,使其只能部署特定资源,那很好——但是,正如您所指出的,每次要部署新资源时,您都需要扩展这些权限。值得注意的是,如果您自动执行此过程,以便在每次添加新基础架构时扩展角色权限 - 您已有效地授予您的部署用户管理访问权限。

这就是为什么大多数人使用过度配置的部署用户来部署他们的应用程序。由于两个原因,这不被认为是一种糟糕的方法:

  1. 您的应用程序在执行时不使用此角色,因此如果您的 lambda 中存在一些允许远程代码执行的重大漏洞,则攻击者无法破坏您的整个 AWS 账户
  2. 您依靠您的 IAC 提供商来确保您不会创建不需要的基础设施。(即:您和您的 IAC 提供商具有相同级别的访问权限)

只要 Lambda 执行角色具有严格的 IAM 策略,使用过度配置的部署用户就可以了。

  • 是的,绝对是。尽管我合作过的大多数组织通常允许其部署角色有很大的自由度,但您始终可以包含对这些类型的特定拒绝。在很多情况下,您的 IAC 提供商都需要创建一个新角色作为部署的一部分(特别是如果您使用 terraform 之类的工具来管理您的员工用户帐户)。在这种情况下,IAM 实际上不允许您阻止策略 IIRC 的特定部分。(因此,允许用户 createRole 可以有效地授予他们管理员访问权限)。在这种情况下,我会限制对代码管道本身的访问。 (2认同)