Understanding the MSK Connect Service Execution Role: When It's Used, Log Delivery Architecture, and Limitations of IAM Last Accessed

When the Service Execution Role Is Used

MSK Connect assumes the service execution role via sts:AssumeRole with the kafkaconnect.amazonaws.com service principal, and uses the resulting temporary credentials to access AWS resources.

The role is not continuously used while a connector is in the RUNNING state. How often the role is assumed depends on the connector's configuration.

When the role IS used:

• Connector creation / restart / failover — downloading the custom plugin JAR from S3 [1]
• Connector update — permission validation [1]
• Temporary credential renewal upon expiration
• Kafka cluster authentication when AuthenticationType=IAM [1]
• Plugin accessing AWS resources (e.g., S3 Sink Connector writing to S3) [1]

When the role is NOT used:

• Kafka access with AuthenticationType=NONE or SASL/SCRAM — IAM authentication is not involved
• Source connectors reading from non-AWS sources (e.g., Debezium MySQL Source) — communicates directly with MySQL via JDBC without calling AWS APIs
• Worker log delivery — explained below

The required permissions and usage frequency of the service execution role vary depending on the connector configuration.

Worker Log Delivery Does Not Use the Service Execution Role

MSK Connect worker logs are classified as Vended Logs [2]. Vended Logs are delivered by the delivery.logs.amazonaws.com service principal, which writes directly to the destination resource [3].

Therefore, the permission basis for worker log delivery (S3, CloudWatch Logs, Firehose) is the destination resource's resource-based policy, not the service execution role (identity-based policy).

Example S3 bucket policy required for log delivery:

{
   "Sid": "AWSLogDeliveryWrite",
   "Effect": "Allow",
   "Principal": { "Service": "delivery.logs.amazonaws.com" },
   "Action": "s3:PutObject",
   "Resource": "arn:aws:s3:::your-bucket/AWSLogs/your-account-id/*",
   "Condition": {
       "StringEquals": {
           "s3:x-amz-acl": "bucket-owner-full-control",
           "aws:SourceAccount": ["your-account-id"]
       }
   }
}

AWS automatically adds this bucket policy when log delivery is first enabled, provided the creator has s3:GetBucketPolicy and s3:PutBucketPolicy permissions [3].

Why IAM "Last Accessed" Cannot Be Used to Determine Role Usage

No activity in IAM Last Accessed does not mean the role is unused:

1. Data plane events are not tracked. IAM Last Accessed only tracks management (control plane) API calls. Data plane actions such as kafka-cluster:ReadData are not recorded. The IAM documentation states: "Action last accessed information is not available for any data plane event." [4]

2. Vended Logs bypass the role entirely. Even if logs are actively being delivered to S3, this activity will not appear in the role's Last Accessed information.

3. There is a tracking delay of up to 4 hours [4].

To accurately determine whether the role is being used, query CloudTrail for AssumeRole events:

filter eventName = "AssumeRole"
   and userIdentity.invokedBy = "kafkaconnect.amazonaws.com"
   and requestParameters.roleArn = "arn:aws:iam::123456789012:role/YourRoleName"
| sort @timestamp desc
| limit 20

Additional Notes

• The service execution role of an existing connector cannot be changed. To use a different role, you must delete the connector and create a new one.
• The service-linked role (AWSServiceRoleForKafkaConnect) cannot be used as the service execution role [1].
• It is recommended to add aws:SourceAccount and aws:SourceArn conditions to the trust policy to prevent the confused deputy problem [1].

References

[1] Understand service execution role - Amazon MSK

[2] Enable logging from AWS services - Amazon CloudWatch Logs

[3] Logs sent to Amazon S3 - Amazon CloudWatch Logs

[4] Refine permissions in AWS using last accessed information - IAM