Updates regarding the role trust policy evaluation change when a role assumes itself

[erictompkins]

I received an email from AWS that I'm not sure what to do. Here is the email:

We contacted you previously regarding an AWS Identity and Access Management (IAM) change delivered on September 21, 2022 that updated an aspect of how role trust policy evaluation behaves when a role assumes itself. With this change, role assumption always requires an explicit role trust policy grant. At that time, we identified one or more roles in this account relying on implicit trust when the role assumes itself. These roles were placed on a temporary allow list to prevent AssumeRole calls from being denied due to the new trust policy evaluation behavior. We advised you to make any necessary changes to your existing processes, code, or configurations to prepare for elimination of the implicit trust behavior. For more information about this behavior change in your account, please review additional details in the blog post "Announcing an Update to IAM Role Trust Policy Behavior" [1].

On February 3, 2023, we announced that starting June 30, 2023, all roles, regardless of allow list status, that attempt to assume themselves will fail with an access denied error unless the role trust policy explicitly grants the permission and the conditions and actions are satisfied.

We are contacting you again to announce that rather than enforcing an explicit trust grant for all roles regardless of allow list status starting June 30, 2023, we will instead automatically remove roles from the allow list based on observed role assumption behavior. Roles on the allow list that we observe either not performing role self-assumption or whose trust policy grants explicit trust with every role assumption over the previous 90 days or more are candidates for removal. A role that performs self-assumption without granting explicit trust at least once over the previous 90 days will be retained on the allow list to give you additional time to make the necessary code or configuration changes. As we announced on December 20, 2022, you can verify whether a specific role self-assumption call by an allow-listed role grants explicit trust by reviewing the corresponding CloudTrail entry and observing a value of “true” for the “explicitTrustGrant” flag.

Automatic removal of candidate roles from the allow list that match the criteria defined above begins on June 30, 2023. You may choose to remove a role from the allow list prior to its identification as a removal candidate if its role assumption behavior matches your use case expectations. For assistance with removing such roles from the allow list, please contact AWS Support [2].

Once a role is removed from the allow list, its role assumption calls will always require an explicit trust grant.

They listed off a few IAM roles. One is an ECS role that was created with the terraform-aws-ecs modules/ecs-service library.

The ECS role has a permission policy called "assume-role"

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::XXXXXXXXX:role/xxx-xxx-task"
        }
    ]
}

It also has a trust policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

Is there something more that we need to do to explicitly allow the role to assume itself?

Thank you for your help.

---

Tracked in ticket #110314

[Etiene]

Hi @erictompkins, apologies for the delay, I was ill this week. Thanks for reporting this! I'm going to create an issue at the ECS module repo now and start investigating this.

[Etiene]

Hi @erictompkins, from what I understood from the AWS blog post mentioned on the message you showed, the arn of the role should be listed in the principals that can assume it. But I can't find which is the offending role in the module. I can see two instances of when sts:AssumeRole is used. One in elb.tf and one in task_definition.tf, but neither of them lists a resource.

Quick question, are you using the ecs module in a standalone way, or are you using the service catalog?

If you are using it standalone, are you setting anything in the variables additional_task_assume_role_policy_principals, elb_role_permissions_boundary_arn, task_role_permissions_boundary_arn, or task_execution_role_permissions_boundary_arn? And are you sure you are using a role created within the module and not one passed through existing_ecs_task_role_name or existing_ecs_task_execution_role_name?

If you are using the service catalog, did you set anything for the variable iam_policy?

[Etiene]

Hi @erictompkins, ping :)

[erictompkins]

We are using the ECS module in a standalone way. We're not using the service catalog.

module "ecs_service" {
  source = "git::[email protected]:gruntwork-io/terraform-aws-ecs.git//modules/ecs-service?ref=v0.34.1"

...other code here


  custom_iam_role_name_prefix       = "${var.service_name}-${var.vpc_name}"
  custom_task_execution_name_prefix = "${var.service_name}-${var.vpc_name}"
  custom_ecs_service_role_name      = "${var.service_name}-${var.vpc_name}"

}

We are not using any of the variables that you mentioned.

We are using the three variables shown in the code above.

We are using `module.ecs_service.ecs_task_iam_role_arn` to reference the role from the module in other places.

So far we haven't seen a negative impact from what AWS is doing. Perhaps these were older roles that were created in earlier versions of the module?

[Etiene]

Thank for these details! this is very helpful, I added them to the issue I created, but since you aren't having any negative effects I'm not going prioritize very highly it right now. Let me know if this starts causing any access denied issues though!