How to restrict which principals can appear in a role's trust policy

0

I'm trying to set up permissions so that my users can create roles and policies and use them to give AWS resources access to other AWS resources, but not use them to give humans access to AWS resources. For instance, I would like a developer to be able to create role and attach policies giving access to an RDS instance and certain SSM parameters, and then attach that role to an EC2 instance. However I do not want that developer to be able to give, say, his college roommate, access to that RDS instance and SSM.

We have an AWS Organization with multiple accounts, mostly split along cost allocation boundaries, and use AWS SSO to control access to them.

My first attempt at this was to create an SSO permission set with permissions to create roles and policies, and then an SCP to limit who can use the roles.

So I created a "Dev" permission set with the PowerUser and IAMReadOnly AWS managed policies, and the following inline policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CreateAndManageDevRolesAndPolicies",
            "Effect": "Allow",
            "Action": [
                "iam:CreateRole",
                "iam:DeleteRole",
                "iam:UpdateRole",
                "iam:PutRolePolicy",
                "iam:AttachRolePolicy",
                "iam:UpdateAssumeRolePolicy",
                "iam:DeleteRolePolicy",
                "iam:DetachRolePolicy",
                "iam:TagRole",
                "iam:UntagRole",
                "iam:CreatePolicy",
                "iam:CreatePolicyVersion",
                "iam:SetDefaultPolicyVersion",
                "iam:DeletePolicy",
                "iam:DeletePolicyVersion",
                "iam:TagPolicy",
                "iam:UntagPolicy"
            ],
            "Resource": [
                "arn:aws:iam::*:role/Dev*",
                "arn:aws:iam::*:policy/Dev*"
            ],
            "Condition": {
                "StringEquals": {
                    "iam:PermissionsBoundary": [
                        "arn:aws:iam::aws:policy/PowerUserAccess"
                    ]
                }
            }
        }
    ]
}

and then this SCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUseOfDevRolesFromExternalAccounts",
      "Effect": "Deny",
      "Action": [
        "sts:AssumeRole"
      ],
      "Resource": [
        "arn:aws:iam::*:role/Dev*"
      ]
    }
  ]
}

the idea here was to test that this SCP was properly denying access to all Dev roles, and then add in some conditions to loosen it up to the access I want.

However, what this SCP actually does is deny access to all of my organization's users (even if they are listed in a Dev role's trust policy), and allow access by all other AWS accounts (as long as they are listed in a Dev role's trust policy). Essentially external-only access to the Dev roles, the exact opposite of what I actually want.

Is there any way to achieve what I'm trying to do?

1 Answer
1

Hi, you can set up a global condition called aws:PrincipalIsAWSService which determines wether the principal is a service or not. More docs on this https://aws.amazon.com/blogs/security/iam-makes-it-easier-to-manage-permissions-for-aws-services-accessing-resources/. Let me know if it hits in the right direction

AWS
answered 2 years ago
  • Definitely a good thing to know, and it was the first time I've seen that, so thanks for pointing it out! If I understand correctly, there would not be much point to using this on a role permissions policy because the principal would always be the role itself, not whatever entity assumed that role. I think that also means that there wouldn't be much use for it in a permissions boundary, permissions set, or a service control policy either, as those all constrain only permissions policies. (continued in next comment)

  • It would be useful in a trust policy if you wanted to limit use of a role to either humans or non-humans. Do I have that right?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions