End of support notice: On May 20, 2026, AWS will end support for AWS IoT Events. After May 20, 2026, you will no longer be able to access the AWS IoT Events console or AWS IoT Events resources. For more information, see [AWS IoT Events end of support](https://docs.aws.amazon.com/iotevents/latest/developerguide/iotevents-end-of-support.html).
# Identity and access management for AWS IoT Events
AWS Identity and Access Management (IAM) is an AWS service that helps an administrator securely control access to AWS resources. IAM administrators control who can be *authenticated* (signed in) and *authorized* (have permissions) to use AWS IoT Events resources. IAM is an AWS service that you can use with no additional charge.
**Topics**
+ [Audience](#security_iam_audience)
+ [Authenticating with identities](security_iam_authentication.md)
+ [Managing access using policies](security_iam_access-manage.md)
+ [More about identity and access management](#security_iam_learn-more)
+ [How AWS IoT Events works with IAM](#security_iam_service-with-iam)
+ [AWS IoT Events identity-based policy examples](security_iam_id-based-policy-examples.md)
+ [Cross-service confused deputy prevention for AWS IoT Events](cross-service-confused-deputy-prevention.md)
+ [Troubleshoot AWS IoT Events identity and access](security_iam_troubleshoot.md)
## Audience
How you use AWS Identity and Access Management (IAM) differs based on your role:
+ **Service user** - request permissions from your administrator if you cannot access features (see [Troubleshoot AWS IoT Events identity and access](security_iam_troubleshoot.md))
+ **Service administrator** - determine user access and submit permission requests (see [How AWS IoT Events works with IAM](#security_iam_service-with-iam))
+ **IAM administrator** - write policies to manage access (see [AWS IoT Events identity-based policy examples](security_iam_id-based-policy-examples.md))
# Authenticating with identities
Authentication is how you sign in to AWS using your identity credentials. You must be authenticated as the AWS account root user, an IAM user, or by assuming an IAM role.
You can sign in as a federated identity using credentials from an identity source like AWS IAM Identity Center (IAM Identity Center), single sign-on authentication, or Google/Facebook credentials. For more information about signing in, see [How to sign in to your AWS account](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) in the *AWS Sign-In User Guide*.
For programmatic access, AWS provides an SDK and CLI to cryptographically sign requests. For more information, see [AWS Signature Version 4 for API requests](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) in the *IAM User Guide*.
## AWS account root user
When you create an AWS account, you begin with one sign-in identity called the AWS account *root user* that has complete access to all AWS services and resources. We strongly recommend that you don't use the root user for everyday tasks. For tasks that require root user credentials, see [Tasks that require root user credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) in the *IAM User Guide*.
## IAM users and groups
An *[IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* is an identity with specific permissions for a single person or application. We recommend using temporary credentials instead of IAM users with long-term credentials. For more information, see [Require human users to use federation with an identity provider to access AWS using temporary credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) in the *IAM User Guide*.
An [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) specifies a collection of IAM users and makes permissions easier to manage for large sets of users. For more information, see [Use cases for IAM users](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) in the *IAM User Guide*.
## IAM roles
An *[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* is an identity with specific permissions that provides temporary credentials. You can assume a role by [switching from a user to an IAM role (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) or by calling an AWS CLI or AWS API operation. For more information, see [Methods to assume a role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) in the *IAM User Guide*.
IAM roles are useful for federated user access, temporary IAM user permissions, cross-account access, cross-service access, and applications running on Amazon EC2. For more information, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.
# Managing access using policies
You control access in AWS by creating policies and attaching them to AWS identities or resources. A policy defines permissions when associated with an identity or resource. AWS evaluates these policies when a principal makes a request. Most policies are stored in AWS as JSON documents. For more information about JSON policy documents, see [Overview of JSON policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) in the *IAM User Guide*.
Using policies, administrators specify who has access to what by defining which **principal** can perform **actions** on what **resources**, and under what **conditions**.
By default, users and roles have no permissions. An IAM administrator creates IAM policies and adds them to roles, which users can then assume. IAM policies define permissions regardless of the method used to perform the operation.
## Identity-based policies
Identity-based policies are JSON permissions policy documents that you attach to an identity (user, group, or role). These policies control what actions identities can perform, on which resources, and under what conditions. To learn how to create an identity-based policy, see [Define custom IAM permissions with customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) in the *IAM User Guide*.
Identity-based policies can be *inline policies* (embedded directly into a single identity) or *managed policies* (standalone policies attached to multiple identities). To learn how to choose between managed and inline policies, see [Choose between managed policies and inline policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) in the *IAM User Guide*.
## Other policy types
AWS supports additional policy types that can set the maximum permissions granted by more common policy types:
+ **Permissions boundaries** – Set the maximum permissions that an identity-based policy can grant to an IAM entity. For more information, see [Permissions boundaries for IAM entities](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) in the *IAM User Guide*.
+ **Service control policies (SCPs)** – Specify the maximum permissions for an organization or organizational unit in AWS Organizations. For more information, see [Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) in the *AWS Organizations User Guide*.
+ **Resource control policies (RCPs)** – Set the maximum available permissions for resources in your accounts. For more information, see [Resource control policies (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) in the *AWS Organizations User Guide*.
+ **Session policies** – Advanced policies passed as a parameter when creating a temporary session for a role or federated user. For more information, see [Session policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) in the *IAM User Guide*.
## Multiple policy types
When multiple types of policies apply to a request, the resulting permissions are more complicated to understand. To learn how AWS determines whether to allow a request when multiple policy types are involved, see [Policy evaluation logic](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) in the *IAM User Guide*.
## More about identity and access management
For more information about identity and access management for AWS IoT Events, continue to the following pages:
+ [How AWS IoT Events works with IAM](#security_iam_service-with-iam)
+ [Troubleshoot AWS IoT Events identity and access](security_iam_troubleshoot.md)
## How AWS IoT Events works with IAM
Before you use IAM to manage access to AWS IoT Events, you should understand what IAM features are available to use with AWS IoT Events. To get a high-level view of how AWS IoT Events and other AWS services work with IAM, see [AWS services that work with IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) in the *IAM User Guide*.
**Topics**
+ [AWS IoT Events identity-based policies](#security_iam_service-with-iam-id-based-policies)
+ [AWS IoT Events resource-based policies](#security_iam_service-with-iam-resource-based-policies)
+ [Authorization based on AWS IoT Events tags](#security_iam_service-with-iam-tags)
+ [AWS IoT Events IAM roles](#security_iam_service-with-iam-roles)
### AWS IoT Events identity-based policies
With IAM identity-based policies, you can specify allowed or denied actions and resources as well as the conditions under which actions are allowed or denied. AWS IoT Events supports specific actions, resources, and condition keys. To learn about all of the elements that you use in a JSON policy, see [IAM JSON policy elements reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) in the *IAM User Guide*.
#### Actions
The `Action` element of an IAM identity-based policy describes the specific action or actions that will be allowed or denied by the policy. Policy actions usually have the same name as the associated AWS API operation. The action is used in a policy to grant permissions to perform the associated operation.
Policy actions in AWS IoT Events use the following prefix before the action: `iotevents:`. For example, to grant someone permission to create an AWS IoT Events input with the AWS IoT Events `CreateInput` API operation, you include the `iotevents:CreateInput` action in their policy. To grant someone permission to send an input with the AWS IoT Events `BatchPutMessage` API operation, you include the `iotevents-data:BatchPutMessage` action in their policy. Policy statements must include either an `Action` or `NotAction` element. AWS IoT Events defines its own set of actions that describe tasks that you can perform with this service.
To specify multiple actions in a single statement, separate them with commas as follows:
```
"Action": [
"iotevents:action1",
"iotevents:action2"
```
You can specify multiple actions using wildcards (\$1). For example, to specify all actions that begin with the word `Describe`, include the following action:
```
"Action": "iotevents:Describe*"
```
To see a list of AWS IoT Events actions, see [Actions Defined by AWS IoT Events](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsiotevents.html#awsiotevents-actions-as-permissions) in the *IAM User Guide*.
#### Resources
The `Resource` element specifies the object or objects to which the action applies. Statements must include either a `Resource` or a `NotResource` element. You specify a resource using an ARN or using the wildcard (\$1) to indicate that the statement applies to all resources.
The AWS IoT Events detector model resource has the following ARN:
```
arn:${Partition}:iotevents:${Region}:${Account}:detectorModel/${detectorModelName}
```
For more information about the format of ARNs, see [Identify AWS resources with Amazon Resource Names (ARNs)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html).
For example, to specify the `Foobar` detector model in your statement, use the following ARN:
```
"Resource": "arn:aws:iotevents:us-east-1:123456789012:detectorModel/Foobar"
```
To specify all instances that belong to a specific account, use the wildcard (\$1):
```
"Resource": "arn:aws:iotevents:us-east-1:123456789012:detectorModel/*"
```
Some AWS IoT Events actions, such as those for creating resources, cannot be performed on a specific resource. In those cases, you must use the wildcard (\$1).
```
"Resource": "*"
```
Some AWS IoT Events API actions involve multiple resources. For example, `CreateDetectorModel` references inputs in its condition statements, so a user must have permissions to use the input and the detector model. To specify multiple resources in a single statement, separate the ARNs with commas.
```
"Resource": [
"resource1",
"resource2"
```
To see a list of AWS IoT Events resource types and their ARNs, see [Resources Defined by AWS IoT Events](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsiotevents.html#awsiotevents-resources-for-iam-policies) in the *IAM User Guide*. To learn with which actions you can specify the ARN of each resource, see [Actions Defined by AWS IoT Events](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsiotevents.html#awsiotevents-actions-as-permissions).
#### Condition keys
The `Condition` element (or `Condition` *block*) lets you specify conditions in which a statement is in effect. The `Condition` element is optional. You can build conditional expressions that use [condition operators](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), such as equals or less than, to match the condition in the policy with values in the request.
If you specify multiple `Condition` elements in a statement, or multiple keys in a single `Condition` element, AWS evaluates them using a logical `AND` operation. If you specify multiple values for a single condition key, AWS evaluates the condition using a logical `OR` operation. All of the conditions must be met before the statement's permissions are granted.
You can also use placeholder variables when you specify conditions. For example, you can grant a user permission to access a resource only if it is tagged with their user name. For more information, see [IAM policy elements: Variables and tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html) in the *IAM User Guide*.
AWS IoT Events does not provide any service-specific condition keys, but it does support using some global condition keys. To see all AWS global condition keys, see [AWS global condition context keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) in the *IAM User Guide*."
#### Examples
To view examples of AWS IoT Events identity-based policies, see [AWS IoT Events identity-based policy examples](security_iam_id-based-policy-examples.md).
### AWS IoT Events resource-based policies
AWS IoT Events does not support resource-based policies." To view an example of a detailed resource-based policy page, see [https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html).
### Authorization based on AWS IoT Events tags
You can attach tags to AWS IoT Events resources or pass tags in a request to AWS IoT Events. To control access based on tags, you provide tag information in the [condition element](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) of a policy using the `iotevents:ResourceTag/key-name`, `aws:RequestTag/key-name`, or `aws:TagKeys` condition keys. For more information about tagging AWS IoT Events resources, see [Tagging your AWS IoT Events resources](tagging-iotevents.md).
To view an example identity-based policy for limiting access to a resource based on the tags on that resource, see [View AWS IoT Events inputs based on tags](security_iam_id-based-policy-examples-view-input-tags.md).
### AWS IoT Events IAM roles
An [IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) is an entity within your AWS account that has specific permissions.
#### Using temporary credentials with AWS IoT Events
You can use temporary credentials to sign in with federation, assume an IAM role, or to assume a cross-account role. You obtain temporary security credentials by calling AWS Security Token Service (AWS STS) API operations such as [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) or [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
AWS IoT Events does not support using temporary credentials.
#### Service-linked roles
[Service-linked roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) allow AWS services to access resources in other services to complete an action on your behalf. Service-linked roles appear in your IAM account and are owned by the service. An IAM administrator can view but not edit the permissions for service-linked roles.
AWS IoT Events does not support service-linked roles.
#### Service roles
This feature allows a service to assume a [service role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#id_roles_terms-and-concepts) on your behalf. This role allows the service to access resources in other services to complete an action on your behalf. Service roles appear in your IAM account and are owned by the account. This means that an IAM administrator can change the permissions for this role. However, doing so might break the functionality of the service.
AWS IoT Events supports service roles.
# AWS IoT Events identity-based policy examples
By default, users and roles don't have permission to create or modify AWS IoT Events resources. They also can't perform tasks using the AWS Management Console, AWS CLI, or AWS API. An IAM administrator must create IAM policies that grant users and roles permission to perform specific API operations on the specified resources they need. The administrator must then attach those policies to the users or groups that require those permissions.
To learn how to create an IAM identity-based policy using these example JSON policy documents, see [Creating policies on the JSON tab](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) in the *IAM User Guide*.
**Topics**
+ [Policy best practices](security_iam_service-with-iam-policy-best-practices.md)
+ [Using the AWS IoT Events console](security_iam_id-based-policy-examples-console.md)
+ [Allow users to view their own permissions in AWS IoT Events](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Access one AWS IoT Events input](security_iam_id-based-policy-examples-access-one-input.md)
+ [View AWS IoT Events inputs based on tags](security_iam_id-based-policy-examples-view-input-tags.md)
# Policy best practices
Identity-based policies are very powerful. They determine whether someone can create, access, or delete AWS IoT Events resources in your account. These actions can incur costs for your AWS account. When you create or edit identity-based policies, follow these guidelines and recommendations:
+ **Get Started Using AWS Managed Policies** – To start using AWS IoT Events quickly, use AWS managed policies to give your employees the permissions they need. These policies are already available in your account and are maintained and updated by AWS. For more information, see [Get started using permissions with AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-use-aws-defined-policies) in the *IAM User Guide*.
+ **Grant Least Privilege** – When you create custom policies, grant only the permissions required to perform a task. Start with a minimum set of permissions and grant additional permissions as necessary. Doing so is more secure than starting with permissions that are too lenient and then trying to tighten them later. For more information, see [Grant least privilege](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#grant-least-privilege) in the *IAM User Guide*.
+ **Enable MFA for Sensitive Operations** – For extra security, require users to use multi-factor authentication (MFA) to access sensitive resources or API operations. For more information, see [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) in the *IAM User Guide*.
+ **Use Policy Conditions for Extra Security** – To the extent that it's practical, define the conditions under which your identity-based policies allow access to a resource. For example, you can write conditions to specify a range of allowable IP addresses that a request must come from. You can also write conditions to allow requests only within a specified date or time range, or to require the use of SSL or MFA. For more information, see [IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
# Using the AWS IoT Events console
To access the AWS IoT Events console, you must have a minimum set of permissions. These permissions must allow you to list and view details about the AWS IoT Events resources in your AWS account. If you create an identity-based policy that is more restrictive than the minimum required permissions, the console won't function as intended for entities (users or roles) with that policy.
To ensure that those entities can still use the AWS IoT Events console, also attach the following AWS managed policy to the entities. For more information, see [ Adding permissions to a user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iotevents:BatchPutMessage",
"iotevents:BatchUpdateDetector",
"iotevents:CreateDetectorModel",
"iotevents:CreateInput",
"iotevents:DeleteDetectorModel",
"iotevents:DeleteInput",
"iotevents:DescribeDetector",
"iotevents:DescribeDetectorModel",
"iotevents:DescribeInput",
"iotevents:DescribeLoggingOptions",
"iotevents:ListDetectorModelVersions",
"iotevents:ListDetectorModels",
"iotevents:ListDetectors",
"iotevents:ListInputs",
"iotevents:ListTagsForResource",
"iotevents:PutLoggingOptions",
"iotevents:TagResource",
"iotevents:UntagResource",
"iotevents:UpdateDetectorModel",
"iotevents:UpdateInput",
"iotevents:UpdateInputRouting"
],
"Resource": "arn:aws:iotevents:us-east-1:123456789012:detectorModel/your-detector-model-name",
"Resource": "arn:aws:iotevents:us-east-1:123456789012:input/your-input-name"
}
]
}
```
------
You don't need to allow minimum console permissions for users that are making calls only to the AWS CLI or the AWS API. Instead, allow access to only the actions that match the API operation that you're trying to perform.
# Allow users to view their own permissions in AWS IoT Events
This example shows how you might create a policy that allows users to view the inline and managed policies that are attached to their user identity. Allowing users to view their own IAM permissions is useful for security awareness and self-service capabilities. This policy includes permissions to complete this action on the console or programmatically using the AWS CLI or AWS API.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": [
"arn:aws:iam::*:user/${aws:username}"
]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
------
# Access one AWS IoT Events input
Granular access control to AWS IoT Events inputs is important for maintaining security in multi-user or multi-team environments. This section shows how to create IAM policies that grant access to specific AWS IoT Events inputs while restricting access to others.
In this example, you can grant a user in your AWS account access to one of your AWS IoT Events inputs, `exampleInput`. You also can allow the user to add, update, and delete inputs.
The policy grants the `iotevents:ListInputs`, `iotevents:DescribeInput`, `iotevents:CreateInput`, `iotevents:DeleteInput`, and `iotevents:UpdateInput` permissions to the user. For an example walkthrough for the Amazon Simple Storage Service (Amazon S3) that grants permissions to users and tests them using the console, see [Controlling access to a bucket with user policies](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"ListInputsInConsole",
"Effect":"Allow",
"Action":[
"iotevents:ListInputs"
],
"Resource":"arn:aws:iotevents:us-east-2:123456789012:input/*"
},
{
"Sid":"ViewSpecificInputInfo",
"Effect":"Allow",
"Action":[
"iotevents:DescribeInput"
],
"Resource":"arn:aws:iotevents:us-east-1:123456789012:input/inputName"
},
{
"Sid":"ManageInputs",
"Effect":"Allow",
"Action":[
"iotevents:CreateInput",
"iotevents:DeleteInput",
"iotevents:DescribeInput",
"iotevents:ListInputs",
"iotevents:UpdateInput"
],
"Resource":"arn:aws:iotevents:us-east-1:123456789012:input/*"
}
]
}
```
------
# View AWS IoT Events inputs based on tags
Tags help you organize AWS IoT Events resources. You can use conditions in your identity-based policy to control access to AWS IoT Events resources based on tags. This example shows how you might create a policy that allows viewing an *input*. However, permission is granted only if the *input* tag `Owner` has the value of that user's user name. This policy also grants the permissions necessary to complete this action on the console.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ListInputsInConsole",
"Effect": "Allow",
"Action": "iotevents:ListInputs",
"Resource": "*"
},
{
"Sid": "ViewInputsIfOwner",
"Effect": "Allow",
"Action": "iotevents:ListInputs",
"Resource": "arn:aws:iotevents:*:*:input/*",
"Condition": {
"StringEquals": {"aws:ResourceTag/Owner": "${aws:username}"}
}
}
]
}
```
------
You can attach this policy to the users in your account. If a user named `richard-roe` attempts to view an AWS IoT Events *input*, the *input* must be tagged `Owner=richard-roe` or `owner=richard-roe`. Otherwise he is denied access. The condition tag key `Owner` matches both `Owner` and `owner` because condition key names are not case-sensitive. For more information, see [IAM JSON policy elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) in the *IAM User Guide*.
# Cross-service confused deputy prevention for AWS IoT Events
**Note**
The AWS 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 AWS 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 AWS 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 AWS, 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, AWS 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.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceaccount) global condition context keys in resource policies to limit the permissions that AWS 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:iotevents:*:123456789012:*`.
The following examples show how you can use the `aws:SourceArn` and `aws:SourceAccount` global condition context keys in AWS IoT Events to prevent the confused deputy problem.
**Topics**
+ [Example: Secure access to an AWS IoT Events detector model](accessing-a-detector-model.md)
+ [Example: Secure access to an AWS IoT Events alarm model](accessing-an-alarm-model.md)
+ [Example: Access an AWS IoT Events resource in a specified region](accessing-resource-in-specified-region.md)
+ [Example: Configure logging options for AWS IoT Events](logging-options.md)
# Example: Secure access to an AWS IoT Events detector model
This example demonstrates how to create an IAM policy that securely grants access to a specific detector model in AWS IoT Events. The policy uses conditions to ensure that only the specified AWS account and AWS 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:iotevents:us-east-1:123456789012:detectorModel/WindTurbine01"
}
}
}
]
}
```
------
# Example: Secure access to an AWS IoT Events alarm model
This example demonstrates how to create an IAM policy that allows AWS IoT Events to securely access alarm models. The policy uses conditions to ensure that only the specified AWS account and AWS IoT Events service can assume the role.
In this example, the role can access any alarm model within the specified AWS 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:iotevents:us-east-1:123456789012:alarmModel/*"
}
}
}
]
}
```
------
# Example: Access an AWS IoT Events resource in a specified region
This example demonstrates how to configure an IAM role to access AWS IoT Events resources in a specific AWS region. By using region-specific ARNs in your IAM policies, you can restrict access to AWS 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:iotevents:us-east-1:123456789012:*"
}
}
}
]
}
```
------
# Example: Configure logging options for AWS IoT Events
Proper logging is important for monitoring, debugging, and auditing your AWS IoT Events applications. This section provides an overview of logging options available in AWS IoT Events.
This example demonstrates how to configure an IAM role that allows AWS IoT Events to log data to CloudWatch Logs. The use of wildcards (`*`) in the resource ARN allows for comprehensive logging across your AWS 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:iotevents:us-east-1:123456789012:*"
}
}
}
]
}
```
------
# Troubleshoot AWS IoT Events identity and access
Use the following information to help you diagnose and fix common issues that you might encounter when working with AWS IoT Events and IAM.
**Topics**
+ [I am not authorized to perform an action in AWS IoT Events](#security_iam_troubleshoot-no-permissions)
+ [I am not authorized to perform `iam:PassRole`](#security_iam_troubleshoot-passrole)
+ [I want to allow people outside of my AWS account to access my AWS IoT Events resources](#security_iam_troubleshoot-cross-account-access)
## I am not authorized to perform an action in AWS IoT Events
If the AWS Management Console tells you that you're not authorized to perform an action, then you must contact your administrator for assistance. Your administrator is the person that provided you with your user name and password.
The following example error occurs when the `mateojackson` IAM user tries to use the console to view details about a *input* but does not have `iotevents:ListInputs` permissions.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: iotevents:ListInputs on resource: my-example-input
```
In this case, Mateo asks his administrator to update his policies to allow him to access the `my-example-input` resource using the `iotevents:ListInput` action.
## I am not authorized to perform `iam:PassRole`
If you receive an error that you're not authorized to perform the `iam:PassRole` action, your policies must be updated to allow you to pass a role to AWS IoT Events.
Some AWS services allow you to pass an existing role to that service instead of creating a new service role or service-linked role. To do this, you must have permissions to pass the role to the service.
The following example error occurs when an IAM user named `marymajor` tries to use the console to perform an action in AWS IoT Events. However, the action requires the service to have permissions that are granted by a service role. Mary does not have permissions to pass the role to the service.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
In this case, Mary's policies must be updated to allow her to perform the `iam:PassRole` action.
If you need help, contact your AWS administrator. Your administrator is the person who provided you with your sign-in credentials.
## I want to allow people outside of my AWS account to access my AWS IoT Events resources
You can create a role that users in other accounts or people outside of your organization can use to access your resources. You can specify who is trusted to assume the role. For services that support resource-based policies or access control lists (ACLs), you can use those policies to grant people access to your resources.
Consult the following topics to determine your best options:
+ To learn whether AWS IoT Events supports these features, see [How AWS IoT Events works with IAM](security-iam.md#security_iam_service-with-iam).
+ To learn how to provide access to your resources across AWS accounts that you own, see [Providing access to an IAM user in another AWS account that you own](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) in the *IAM User Guide*.
+ To learn how to provide access to your resources to third-party AWS accounts, see [Providing access to AWS accounts owned by third parties](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) in the *IAM User Guide*.
+ To learn how to provide access through identity federation, see [Providing access to externally authenticated users (identity federation)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) in the *IAM User Guide*.
+ To learn the difference between using roles and resource-based policies for cross-account access, see [Cross account resource access in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) in the *IAM User Guide*.