Question

我一直在测试我的持续部署设置，试图获得一组最小的IAM权限，这将允许我的CI IAM组部署到我的“staging”Elastic Beanstalk环境。

在我的最新测试中，我的部署卡住了。控制台中的最后一个事件是：

Updating environment staging's configuration settings.

幸运的是，部署将在30分钟后超时，因此可以再次部署环境。

这似乎是一个权限问题，因为如果我在所有资源上授予s3:*，则部署可以正常工作。似乎在调用UpdateEnvironment时，Elastic Beanstalk对S3做了一些事情，但我无法弄清楚是什么。

我已经尝试了以下策略来授予EB对其资源桶的完全访问权限：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*"
            ],
            "Resource": [
                "arn:aws:s3:::elasticbeanstalk-REGION-ACCOUNT/resources/_runtime/_embedded_extensions/APP",
                "arn:aws:s3:::elasticbeanstalk-REGION-ACCOUNT/resources/_runtime/_embedded_extensions/APP/*",
                "arn:aws:s3:::elasticbeanstalk-REGION-ACCOUNT/resources/environments/ENV_ID",
                "arn:aws:s3:::elasticbeanstalk-REGION-ACCOUNT/resources/environments/ENV_ID/*"
            ]
        }
    ]
}

REGION，ACCOUNT，APP和ENV_ID分别是我的AWS区域，帐号，应用程序名称和环境ID。

有没有人知道S3动作和资源EB试图访问哪些？

Answer 1

Shared this on your blog already，但这可能会有更广泛的受众，所以在这里：

对此进行了跟进，ElastiBeanstalk团队为我提供了有关S3权限的以下答案：

“[...]看到下面的要求，稍微锁定的版本会起作用吗？我已经在这个案例中附加了一个策略，该策略将使用elasticbeanstalk从桶中授予s3：GetObject。这主要是为了允许访问所有的elasticbeanstalk存储桶，包括我们拥有的存储桶。你唯一需要做的就是使用GetObject，所以这应该足以完成你需要的一切。“

所以看起来ElasticBeanstalk正在从任何人的领域访问存储桶以便正常工作（这有点糟糕，但这就是它的方式）。

由此可以得出以下政策足以使S3与之合作：

{
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::elasticbeanstalk-<region>-<account_id>",
    "arn:aws:s3:::elasticbeanstalk-<region>-<account_id>/",
    "arn:aws:s3:::elasticbeanstalk-<region>-<account_id>/*"
  ],
  "Effect": "Allow"
},
{
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::elasticbeanstalk*",
  "Effect": "Allow"
}

显然，您需要将其包含在IAM理解的适当政策声明中。您之前关于IAM策略的所有假设都证明是正确的，所以我猜这不应该是一个问题。

Elastic Beanstalk部署停留在更新配置设置上

1 个答案: