End of support notice: On May 20, 2026, Amazon will end support for Amazon IoT Events. After May 20, 2026, you will no longer be able to access the Amazon IoT Events console or Amazon IoT Events resources. For more information, see [Amazon IoT Events end of support](https://docs.amazonaws.cn/iotevents/latest/developerguide/iotevents-end-of-support.html). # Cross-service confused deputy prevention for Amazon IoT Events **Note** The Amazon IoT Events service only allows you to use roles to start actions in the same account in which a resource was created. This helps prevent a confused deputy attack in Amazon IoT Events. This page serves as a reference for you to see how the confused deputy issue works and can be prevented in the event that cross account resources were allowed in the Amazon IoT Events service. The confused deputy problem is a security issue where an entity that doesn't have permission to perform an action can coerce a more-privileged entity to perform the action. In Amazon, cross-service impersonation can result in the confused deputy problem. Cross-service impersonation can occur when one service (the *calling service*) calls another service (the *called service*). The calling service can be manipulated to use its permissions to act on another customer's resources in a way it should not otherwise have permission to access. To prevent this, Amazon provides tools that help you protect your data for all services with service principals that have been given access to resources in your account. We recommend using the [https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.amazonaws.cn/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies to limit the permissions that Amazon IoT Events gives another service to the resource. If the `aws:SourceArn` value does not contain the account ID, such as an Amazon S3 bucket ARN, you must use both global condition context keys to limit permissions. If you use both global condition context keys and the `aws:SourceArn` value contains the account ID, the `aws:SourceAccount` value and the account in the `aws:SourceArn` value must use the same account ID when used in the same policy statement. Use `aws:SourceArn` if you want only one resource to be associated with the cross-service access. Use `aws:SourceAccount` if you want to allow any resource in that account to be associated with the cross-service use. The value of `aws:SourceArn` must be the Detector Model or Alarm model associated with the `sts:AssumeRole` request. The most effective way to protect against the confused deputy problem is to use the `aws:SourceArn` global condition context key with the full ARN of the resource. If you don't know the full ARN of the resource or if you are specifying multiple resources, use the `aws:SourceArn` global context condition key with wildcards (`*`) for the unknown portions of the ARN. For example, `arn:aws-cn:iotevents:*:123456789012:*`. The following examples show how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in Amazon IoT Events to prevent the confused deputy problem. **Topics** + [ # Example: Secure access to an Amazon IoT Events detector model ](accessing-a-detector-model.md) + [ # Example: Secure access to an Amazon IoT Events alarm model ](accessing-an-alarm-model.md) + [ # Example: Access an Amazon IoT Events resource in a specified region ](accessing-resource-in-specified-region.md) + [ # Example: Configure logging options for Amazon IoT Events ](logging-options.md) # Example: Secure access to an Amazon IoT Events detector model Example: Secure access to a detector model This example demonstrates how to create an IAM policy that securely grants access to a specific detector model in Amazon IoT Events. The policy uses conditions to ensure that only the specified Amazon account and Amazon IoT Events service can assume the role, adding an extra layer of security. In this example, the role can only access the detector model named *WindTurbine01*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "iotevents.amazonaws.com" ] }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnEquals": { "aws:SourceArn": "arn:aws-cn:iotevents:us-east-1:123456789012:detectorModel/WindTurbine01" } } } ] } ``` ------ # Example: Secure access to an Amazon IoT Events alarm model This example demonstrates how to create an IAM policy that allows Amazon IoT Events to securely access alarm models. The policy uses conditions to ensure that only the specified Amazon account and Amazon IoT Events service can assume the role. In this example, the role can access any alarm model within the specified Amazon account, as indicated by the `*` wildcard in the alarm model ARN. The `aws:SourceAccount` and `aws:SourceArn` conditions work together to prevent the confused deputy problem. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "iotevents.amazonaws.com" ] }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnEquals": { "aws:SourceArn": "arn:aws-cn:iotevents:us-east-1:123456789012:alarmModel/*" } } } ] } ``` ------ # Example: Access an Amazon IoT Events resource in a specified region Example: Access a resource in a specified region This example demonstrates how to configure an IAM role to access Amazon IoT Events resources in a specific Amazon region. By using region-specific ARNs in your IAM policies, you can restrict access to Amazon IoT Events resources across different geographical areas. This approach can help maintain security and compliance in multi-region deployments. The region in this example is *us-east-1*. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "iotevents.amazonaws.com" ] }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnEquals": { "aws:SourceArn": "arn:aws-cn:iotevents:us-east-1:123456789012:*" } } } ] } ``` ------ # Example: Configure logging options for Amazon IoT Events Example: Configure logging options; Proper logging is important for monitoring, debugging, and auditing your Amazon IoT Events applications. This section provides an overview of logging options available in Amazon IoT Events. This example demonstrates how to configure an IAM role that allows Amazon IoT Events to log data to CloudWatch Logs. The use of wildcards (`*`) in the resource ARN allows for comprehensive logging across your Amazon IoT Events infrastructure. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "iotevents.amazonaws.com" ] }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "123456789012" }, "ArnEquals": { "aws:SourceArn": "arn:aws-cn:iotevents:us-east-1:123456789012:*" } } } ] } ``` ------