We recently noticed an interesting error in CloudTrail across multiple accounts:
"errorMessage": "User: arn:aws:sts::123456789012:assumed-role/AwsConfigServiceRole/ConfigResourceCompositionSession is not authorized to perform: iam:CreateServiceLinkedRole on resource: arn:aws:iam::123456789012:role/aws-service-role/globalaccelerator.amazonaws.com/AWSServiceRoleForGlobalAccelerator because no identity-based policy allows the iam:CreateServiceLinkedRole action"
According the above message, it looks like the AWS Config service role was trying to create the service linked role for Global Accelerator. The denial is expected, as the AWS managed policy for AWS Config does not include the iam:CreateServiceLinkedRole permission. But the question is why AWS service linked role is trying to creating another service linked role?
It turns out to be a bug that was introduced recently:
Config service recently released recording support for GlobalAccelerator. Config Recorder uses the GlobalAccelerator ListAccelerators API to list the existing GlobalAccelerators in the account.
However, if the account is not already using GlobalAccelerators, meaning the GlobalAccelerators service-linked role does not exist, the ListAccelerators API will attempt to call subsequent CreateServiceLinkedRole API to create this service-linked role. Because the Config Role is not supposed to create service-linked role, thus the AWSConfigRole policy does not grant CreateServiceLinkedRole permission, and API call failed with access denied.
The service team is aware of this issue, and they are actively working on a fix. In the meantime, Config service has rolled back the support for GlobalAccelerator to prevent further access denied CreateServiceLinkedRole API call.AWS support