Cross-service confused deputy prevention - Amazon Kinesis Data Analytics for SQL Applications Developer Guide

For new projects, we recommend that you use the new Kinesis Data Analytics Studio over Kinesis Data Analytics for SQL Applications. Kinesis Data Analytics Studio combines ease of use with advanced analytical capabilities, enabling you to build sophisticated stream processing applications in minutes.

Cross-service confused deputy prevention

In AWS, cross-service impersonation can occur when one service (the calling service) calls another service (the called service). The calling service can be manipulated to act on another customer's resources even though it shouldn't have the proper permissions, resulting in the confused deputy problem.

To prevent confused deputies, AWS provides tools that help you protect your data for all services using service principals that have been given access to resources in your account. This section focuses on cross-service confused deputy prevention specific to Kinesis Data Analytics however, you can learn more about this topic at The confused deputy problem section of the IAM User Guide.

In the context of Kinesis Data Analytics for SQL, we recommend using the aws:SourceArn and aws:SourceAccount global condition context keys in your role trust policy to limit access to the role to only those requests that are generated by expected resources.

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 ARN of the resource used by Kinesis Data Analytics, which is specified with the following format: arn:aws:kinesisanalytics:region:account:resource.

The recommended approach to the confused deputy problem is to use the aws:SourceArn global condition context key with the full resource ARN.

If you don't know the full ARN of the resource or if you are specifying multiple resources, use the aws:SourceArn key with wildcard characters (*) for the unknown portions of the ARN. For example: arn:aws:kinesisanalytics::111122223333:*.

While most actions in the Kinesis Data Analytics for SQL API such as CreateApplication, AddApplicationInput and DeleteApplication are made in context of specific applications, the DiscoverInputSchema action is not executed in the context of any application. That means the role used in this action must not fully specify a resource in the SourceArn condition key. Following is an example that uses a wildcard ARN:

{ ... "ArnLike":{ "aws:SourceArn":"arn:aws:kinesisanalytics:us-east-1:123456789012:*" } ... }

The default role generated by Kinesis Data Analytics for SQL uses this wildcard. This ensures discovering input schema works seamlessly in the console experience. However, we recommend editing the Trust Policy to use a full ARN after discovering the schema to implement complete confused deputy mitigation.

Policies of roles that you provide to Kinesis Data Analytics as well as trust policies of roles generated for you can make use of aws:SourceArn and aws:SourceAccount condition keys.

In order to protect against the confused deputy problem, carry out the following steps:

To protect against the confused deputy problem
  1. Sign in to the AWS Management Console and open the IAM console at

  2. Choose Roles and then choose the role you want to modify.

  3. Choose Edit trust policy.

  4. On the Edit trust policy page, replace the default JSON policy with a policy that uses one or both of the aws:SourceArn and aws:SourceAccount global condition context keys. See the following example policy:

  5. Choose Update policy.

    { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"Account ID" }, "ArnEquals":{ "aws:SourceArn":"arn:aws:kinesisanalytics:us-east-1:123456789012:application/my-app" } } } ] }