【问题标题】:AWS AccessDenied when calling sts:AssumeRole调用 sts:AssumeRole 时 AWS AccessDenied
【发布时间】:2021-01-27 07:52:16
【问题描述】:

我正在尝试允许组中的一组用户访问一个角色,他们可以通过该角色将对象上传到 s3 存储桶。

作为策略的组:

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::ACCOUNTID:role/Clinic_Sync"
    }
}

角色“Clinic_Sync”拥有政策:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "SyncReqs",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::*/*"
        },
        {
            "Sid": "SyncReqs2",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": "arn:aws:s3:::*"
        }
    ]
}

桶有策略:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::ACCOUNTID:role/Clinic_Sync"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::mydata"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::ACCOUNTID:role/Clinic_Sync"
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::mydata/*"
        },
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::mydata",
                "arn:aws:s3:::mydata/*"
            ],
            "Condition": {
                "StringNotLike": {
                    "aws:userId": [
                        "ADMINUSERID:*",
                        "ACCOUNTNO"
                    ]
                }
            }
        }
    ]
}

这个想法是没有人可以访问存储桶,除非通过承担这个角色(除了管理员)。我创建的凭据文件如下:

[default]
aws_access_key_id = ACCESSID1
aws_secret_access_key = SECRETKEY1
[csync]
role_arn = arn:aws:iam::ACCOUNTID:role/Clinic_Sync
source_profile = default

还有配置文件:

[default]
output = json
region = eu-west-2
[profile csync]
role_arn = arn:aws:iam::ACCOUNTID:role/Clinic_Sync
source_profile = default

存储桶策略似乎有效,因为运行命令“aws s3 cp hello.txt s3://mydata”会出现错误:上传失败。调用 PutObject 操作时出错:拒绝访问。

但是当我尝试使用该角色时,使用命令“aws s3 cp hello.txt s3://run3d-data --profile csync”,它给出了这个错误:

upload failed: .\hello.txt to s3://mydata/hello.txt An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::ACCOUNTID:user/TestAcc2 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::ACCOUNTID:role/Clinic_Sync

我多年来一直在网上搜索答案,但找不到任何答案。坦率地说,aws 文档对我来说是难以理解的。如果有人可以帮助我找到解决方案,我将不胜感激,因为我在这里扯头发。

重申一下,我只是希望特定组中的用户能够访问一个角色,该角色授予他们使用 s3 存储桶的权限,但阻止对该存储桶的所有其他访问。

【问题讨论】:

  • 您的TestAcc2 用户是该组的成员吗?
  • 是的,绝对是

标签: amazon-web-services amazon-s3 aws-cli


【解决方案1】:

您的存储桶策略似乎说:“拒绝访问存储桶,除非 aws:userId 是给定的管理员用户 ID 或帐号。它没有引用角色。

因此,通过角色访问存储桶将被拒绝。这是因为拒绝总是覆盖允许。

在这种情况下,使用 Deny 编写策略可能非常困难。

如果您真的想保证存储桶的安全,可以更轻松地将存储桶放在单独的 AWS 账户中,并且只向应该有权访问的实体授予跨账户访问权限。这样,就不需要拒绝策略。


如果您收到 not authorised to perform sts:AssumeRole 错误,请确保信任策略通过在创建角色时选择另一个 AWS 账户选项授予用户访问权限。该政策应类似于:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

【讨论】:

  • 我的存储桶确实引用了该角色。前 2 个语句特定于角色。到目前为止,我所读到的所有内容似乎都建议像我所做的那样编写允许语句将覆盖拒绝语句(如果错了,请纠正我)。此外,我看不到该“修复”将如何影响我遇到的特定错误,这与允许我的用户 TestAcc2 承担角色 Clinic_Sync...
  • 哦,我明白你的意思了!您的意思是 Deny 没有具体引用该角色。啊。对不起,如果我似乎在推后,我只是想了解一些东西!并感谢流程图。很有用!
  • 正确。很难说“拒绝一切,除非他们来自这个角色或者是管理员或者......”。这就是为什么最好只允许首先应该允许的内容。如果这太难了,有时使用单独的帐户会更容易(例如,对于敏感数据,如 HR 信息)。
  • 好的,我已经解决了这个问题,方法是删除拒绝语句并将我的管理员帐户包含在允许语句中。不过,我仍然收到“未授权执行 sts:AssumeRole”错误。有什么我可以错过的吗?我注意到角色附加了信任策略(我的只允许 s3 承担角色)。会不会是这个问题?
猜你喜欢
  • 2021-09-30
  • 2021-12-08
  • 2022-01-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2014-03-24
  • 1970-01-01
相关资源
最近更新 更多