Question

我使用OKTA作为我们的身份提供程序，这使我能够确定用户在登录控制台时可以承担哪些角色。

目标：具有一个角色，该角色允许用户登录控制台并仅管理其访问密钥（列表，创建，更新，删除）。

此政策应该允许当前用户管理自己的密钥，但是尝试执行除列出访问密钥以外的其他操作时，我会收到此错误

User: arn:aws:sts::[ACCOUNT-NUMBER]:assumed-role/AccessKeyManagement/[Logged In Username] is not authorized to perform: iam:CreateAccessKey on resource: user [Logged In Username]

如果我将资源更改为"*"，则可以使用，但是用户可以更改其他帐户的访问密钥。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole",
                "sts:DecodeAuthorizationMessage",
                "iam:ListAccountAliases",
                "iam:ListUsers",
                "sts:GetCallerIdentity",
                "iam:ListAccessKeys"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:DeleteAccessKey",
                "iam:UpdateAccessKey",
                "iam:CreateAccessKey"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}

角色信任关系（以防万一）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::[ACCOUNT-NUMBER]:saml-provider/OKTA"
      },
      "Action": [
        "sts:AssumeRoleWithSAML",
        "sts:AssumeRole"
      ],
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

对于让当前用户的“假定角色”权限修改访问键，我需要做什么。

Answer 1

因此，IAM角色没有与之关联的永久访问密钥，并且在登录控制台时会获得临时凭证（访问密钥，秘密密钥和会话令牌）。现在，“ $ {aws：username}”解析为IAM用户名，并且不适用于IAM角色。因此，您不必管理IAM角色的访问密钥创建，也不必这样做。

SAML假定角色用户无权执行操作

1 个答案: