Change to AWS IAM Role Trust Policy Evaluation

[lkolchin]

With the latest changes to role's self-assumption (https://aws.amazon.com/blogs/security/announcing-an-update-to-iam-role-trust-policy-behavior/)
AWS is warning about the need in Change to AWS IAM Role Trust Policy Evaluation

I think there is a case of - some Lambda functions call sts:AssumeRole with the target role being the very same role that the Lambda function has already been provided as part of its configuration. for
arn:aws:iam::xxxx:role/OrganizationAccountAccessRole

OrganizationAccountAccessRole - is configured in

      let account = new Account(this, key, {
        accountName: value.accountName,
        email: value.email,
        importOnDuplicate: true,
        iamUserAccessToBilling: IamUserAccessToBilling.ALLOW,
        roleName: value.assume_role_name,
        parent: ousMap.get(value.parent),
      });

Here is the email from AWS:

Hello,

After carefully considering feedback from customers, AWS Identity and Access Management (IAM) is changing an aspect of how role trust policy evaluation behaves when a role assumes itself. Please read further to understand this change and actions you may need to take before February 15, 2023.
​
Beginning September 21, 2022, a role trust policy must explicitly grant permission to the principals, including the role itself, that need to assume it under the specified conditions. This change improves consistency with how other AWS resource policies behave and increases visibility into role assumption behavior.

We are contacting you because our data suggests that your AWS account may have one or more IAM Roles that assumes itself based on the permissions and conditions in its identity-based policy without explicitly granted permission in its role trust policy. No roles in your AWS account beyond those shown at the end of the notification exhibit potential for this behavior.

You should see no immediate impact due to the change, because these roles have been allow-listed to continue to behave as before. You may continue to use your existing configuration for the roles listed previously until February 15, 2023. We are allowing time for you to make any necessary changes to existing processes, code, or configuration in preparation for enforcement of an explicit permission grant in the role trust policy. If maintaining the existing behavior of your code is important for your use case, a role can continue to assume itself after February 15, 2023, by updating its role trust policy to explicitly trust the role itself.

After February 15, 2023, all roles 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.

In support of your efforts to address this behavior change in your account, we are providing additional guidance and details in the blog post "Announcing an Update to IAM Role Trust Policy Behavior" [1]. The blog discusses the most common use cases where roles are observed assuming themselves and how you can change your code or configuration prior to February 15, 2023.

For assistance with adding new roles to or removing existing roles from the list shown previously, please contact AWS Support [2].

[1] https://aws.amazon.com/blogs/security/announcing-an-update-to-iam-role-trust-policy-behavior/
[2] https://aws.amazon.com/support

The following are your affected IAM Roles:
arn:aws:iam::123456789012:role/OrganizationAccountAccessRole

[pflorek]

Hey @lkolchin ,

the role name OrganizationAccountAccessRole is the default that will be created by the AWS Organization API call. It's used by the custom resource only as a parameter. Every lambda used has it's own role and shouldn't try to self assume.

cdk-organizations/src/account-provider/on-event-handler.lambda.ts

Lines 25 to 29 in 23929b0

	.createAccount({
	Email: Email,
	AccountName: AccountName,
	RoleName: RoleName,
	IamUserAccessToBilling: IamUserAccessToBilling,

If I read Announcing an update to IAM role trust policy behavior they mention to inspect the CloudTrail logs. Can you provide more insights which lambda / resource is using OrganizationAccountAccessRole?