After careful consideration, we have decided to discontinue Amazon Kinesis Data Analytics for SQL applications: 1. From **September 1, 2025**, we won't provide any bug fixes for Amazon Kinesis Data Analytics for SQL applications because we will have limited support for it, given the upcoming discontinuation. 2. From **October 15, 2025**, you will not be able to create new Kinesis Data Analytics for SQL applications. 3. We will delete your applications starting **January 27, 2026**. You will not be able to start or operate your Amazon Kinesis Data Analytics for SQL applications. Support will no longer be available for Amazon Kinesis Data Analytics for SQL from that time. For more information, see [Amazon Kinesis Data Analytics for SQL Applications discontinuation](discontinuation.md). # Security in Amazon Kinesis Data Analytics Cloud security at AWS is the highest priority. As an AWS customer, you will benefit from a data center and network architecture built to meet the requirements of the most security-sensitive organizations. Security is a shared responsibility between AWS and you. The [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/) describes this as security *of* the cloud and security *in* the cloud: + **Security of the cloud** – AWS is responsible for protecting the infrastructure that runs AWS services in the AWS Cloud. AWS also provides you with services that you can use securely. The effectiveness of our security is regularly tested and verified by third-party auditors as part of the [AWS compliance programs](https://aws.amazon.com/compliance/programs/). To learn about the compliance programs that apply to Kinesis Data Analytics, see [AWS Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). + **Security in the cloud** – Your responsibility is determined by the AWS service that you use. You are also responsible for other factors including the sensitivity of your data, your organization’s requirements, and applicable laws and regulations. This documentation helps you understand how to apply the shared responsibility model when using Kinesis Data Analytics. The following topics show you how to configure Kinesis Data Analytics to meet your security and compliance objectives. You'll also learn how to use other Amazon services that can help you to monitor and secure your Kinesis Data Analytics resources. **Topics** + [Data Protection in Amazon Kinesis Data Analytics for SQL Applications](data-protection.md) + [Identity and Access Management in Kinesis Data Analytics](iam-role.md) + [Authentication and Access Control for](authentication-and-access-control.md) + [Monitoring Amazon Kinesis Data Analytics](security-monitoring.md) + [Compliance Validation for Amazon Kinesis Data Analytics for SQL Applications](akda-java-compliance.md) + [Resilience in Amazon Kinesis Data Analytics](disaster-recovery-resiliency.md) + [Infrastructure Security in Kinesis Data Analytics for SQL Applications](infrastructure-security.md) + [Security Best Practices for Kinesis Data Analytics](security-best-practices.md) # Data Protection in Amazon Kinesis Data Analytics for SQL Applications You can protect your data using tools that are provided by AWS. Kinesis Data Analytics can work with services that support encrypting data, including Kinesis Data Streams, Firehose, and Amazon S3. ## Data Encryption in Kinesis Data Analytics ### Encryption at Rest Note the following about encrypting data at rest with Kinesis Data Analytics: + You can encrypt data on the incoming Kinesis data stream using [StartStreamEncryption](https://docs.aws.amazon.com/kinesis/latest/APIReference/API_StartStreamEncryption.html). For more information, see [What Is Server-Side Encryption for Kinesis Data Streams?](https://docs.aws.amazon.com/streams/latest/dev/what-is-sse.html). + Output data can be encrypted at rest using Firehose to store data in an encrypted Amazon S3 bucket. You can specify the encryption key that your Amazon S3 bucket uses. For more information, see [Protecting Data Using Server-Side Encryption with KMS–Managed Keys (SSE-KMS)](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html). + Your application's code is encrypted at rest. + Your application's reference data is encrypted at rest. ### Encryption In Transit Kinesis Data Analytics encrypts all data in transit. Encryption in transit is enabled for all Kinesis Data Analytics applications and cannot be disabled. Kinesis Data Analytics encrypts data in transit in the following scenarios: + Data in transit from Kinesis Data Streams to Kinesis Data Analytics. + Data in transit between internal components within Kinesis Data Analytics. + Data in transit between Kinesis Data Analytics and Firehose. ### Key Management Data encryption in Kinesis Data Analytics uses service-managed keys. Customer-managed keys are not supported. # Identity and Access Management in Kinesis Data Analytics Amazon Kinesis Data Analytics needs permissions to read records from a streaming source that you specify in your application input configuration. Amazon Kinesis Data Analytics also needs permissions to write your application output to streams that you specify in your application output configuration. You can grant these permissions by creating an IAM role that Amazon Kinesis Data Analytics can assume. Permissions that you grant to this role determine what Amazon Kinesis Data Analytics can do when the service assumes the role. **Note** The information in this section is useful if you want to create an IAM role yourself. When you create an application in the Amazon Kinesis Data Analytics console, the console can create an IAM role for you at that time. The console uses the following naming convention for IAM roles that it creates: ``` kinesis-analytics-ApplicationName ``` After the role is created, you can review the role and attached policies in the IAM console. Each IAM role has two policies attached to it. In the trust policy, you specify who can assume the role. In the permissions policy (there can be one or more), you specify the permissions that you want to grant to this role. The following sections describe these policies, which you can use when you create an IAM role. ## Trust Policy To grant Amazon Kinesis Data Analytics permissions to assume a role to access a streaming or reference source, you can attach the following trust policy to an IAM role: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "kinesisanalytics.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ ## Permissions Policy If you are creating an IAM role to allow Amazon Kinesis Data Analytics to read from an application's streaming source, you must grant permissions for relevant read actions. Depending on your source (for example, an Kinesis stream, a Firehose delivery stream, or a reference source in an Amazon S3 bucket), you can attach the following permissions policy. ### Permissions Policy for Reading an Kinesis Stream ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReadInputKinesis", "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:GetShardIterator", "kinesis:GetRecords", "kinesis:ListShards" ], "Resource": [ "arn:aws:kinesis:us-east-1:123456789012:stream/inputStreamName" ] } ] } ``` ------ ### Permissions Policy for Reading a Firehose Delivery Stream ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "ReadInputFirehose", "Effect": "Allow", "Action": [ "firehose:DescribeDeliveryStream", "firehose:Get*" ], "Resource": [ "arn:aws:firehose:us-east-1:123456789012:deliverystream/inputFirehoseName" ] } ] } ``` ------ **Note** The `firehose:Get*` permission refers to an internal accessor that Kinesis Data Analytics uses to access the stream. There is no public accessor for a Firehose delivery stream. If you direct Amazon Kinesis Data Analytics to write output to external destinations in your application output configuration, you need to grant the following permission to the IAM role. ### Permissions Policy for Writing to a Kinesis Stream ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "WriteOutputKinesis", "Effect": "Allow", "Action": [ "kinesis:DescribeStream", "kinesis:PutRecord", "kinesis:PutRecords" ], "Resource": [ "arn:aws:kinesis:us-east-1:123456789012:stream/output-stream-name" ] } ] } ``` ------ ### Permissions Policy for Writing to a Firehose Delivery Stream ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "WriteOutputFirehose", "Effect": "Allow", "Action": [ "firehose:DescribeDeliveryStream", "firehose:PutRecord", "firehose:PutRecordBatch" ], "Resource": [ "arn:aws:firehose:us-east-1:123456789012:deliverystream/output-firehose-name" ] } ] } ``` ------ ### Permissions Policy for Reading a Reference Data Source from an Amazon S3 Bucket ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": "*" } ] } ``` ------ # 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html) section of the *IAM User Guide*. In the context of Kinesis Data Analytics for SQL, we recommend using the [aws:SourceArn](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-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 (\$1) 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](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/API_CreateApplication.html), [AddApplicationInput](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/API_AddApplicationInput.html) and [DeleteApplication](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/API_DeleteApplication.html) are made in context of specific applications, the [DiscoverInputSchema](https://docs.aws.amazon.com/kinesisanalytics/latest/dev/API_DiscoverInputSchema.html) 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn) and [aws:SourceAccount](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-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 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Choose **Roles** and then choose the role you want to modify. 1. Choose **Edit trust policy**. 1. 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: 1. Choose **Update policy**. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "Service":"kinesisanalytics.amazonaws.com" }, "Action":"sts:AssumeRole", "Condition":{ "StringEquals":{ "aws:SourceAccount":"Account ID" }, "ArnEquals":{ "aws:SourceArn":"arn:aws:kinesisanalytics:us-east-1:123456789012:application/my-app" } } } ] } ``` ------ # Authentication and Access Control for Access to requires credentials. Those credentials must have permissions to access AWS resources, such as an application or an Amazon Elastic Compute Cloud (Amazon EC2) instance. The following sections provide details on how you can use [AWS Identity and Access Management (IAM)](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) and to help secure access to your resources. ## Access Control You can have valid credentials to authenticate your requests, but unless you have permissions you cannot create or access resources. For example, you must have permissions to create an application. The following sections describe how to manage permissions for . We recommend that you read the overview first. + [Overview of Managing Access Permissions to Your Resources](access-control-overview.md) + [Using Identity-Based Policies (IAM Policies) for](using-identity-based-policies.md) + [API Permissions: Actions, Permissions, and Resources Reference](api-permissions-reference.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*. ### Federated identity As a best practice, require human users to use federation with an identity provider to access AWS services using temporary credentials. A *federated identity* is a user from your enterprise directory, web identity provider, or Directory Service that accesses AWS services using credentials from an identity source. Federated identities assume roles that provide temporary credentials. For centralized access management, we recommend AWS IAM Identity Center. For more information, see [What is IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) in the *AWS IAM Identity Center 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*. # Overview of Managing Access Permissions to Your Resources **Warning** For new projects, we recommend that you use the new Managed Service for Apache Flink Studio over for SQL Applications. Managed Service for Apache Flink Studio combines ease of use with advanced analytical capabilities, enabling you to build sophisticated stream processing applications in minutes. To provide access, add permissions to your users, groups, or roles: + Users and groups in AWS IAM Identity Center: Create a permission set. Follow the instructions in [Create a permission set](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) in the *AWS IAM Identity Center User Guide*. + Users managed in IAM through an identity provider: Create a role for identity federation. Follow the instructions in [Create a role for a third-party identity provider (federation)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) in the *IAM User Guide*. + IAM users: + Create a role that your user can assume. Follow the instructions in [Create a role for an IAM user](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) in the *IAM User Guide*. + (Not recommended) Attach a policy directly to a user or add a user to a user group. Follow the instructions in [Adding permissions to a user (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) in the *IAM User Guide*. **Note** An *account administrator* (or administrator user) is a user with administrator privileges. For more information, see [IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) in the *IAM User Guide*. **Topics** + [Resources and Operations](#access-control-resources) + [Understanding Resource Ownership](#access-control-resource-ownership) + [Managing Access to Resources](#manage-access-overview) + [Specifying Policy Elements: Actions, Effects, and Principals](#specify-policy-elements) + [Specifying Conditions in a Policy](#specifying-conditions-overview) ## Resources and Operations In , the primary resource is *an application*. In a policy, you use an Amazon Resource Name (ARN) to identify the resource that the policy applies to. These resources have unique Amazon Resource Names (ARNs) associated with them, as shown in the following table. **** | Resource Type | ARN Format | | --- | --- | | Application | `arn:aws:kinesisanalytics:region:account-id:application/application-name` | provides a set of operations to work with resources. For a list of available operations, see [Actions](API_Operations.md). ## Understanding Resource Ownership The AWS account owns the resources that are created in the account, regardless of who created the resources. Specifically, the resource owner is the AWS account of the [principal entity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html) (that is, the root account, a user, or an IAM role) that authenticates the resource creation request. The following examples illustrate how this works: + If you use the root account credentials of your AWS account to create an application, your AWS account is the owner of the resource. (In , the resource is an application.) + If you create a user in your AWS account and grant permissions to create an application to that user, the user can create an application. However, your AWS account, to which the user belongs, owns the application resource. We strongly recommend you grant permissions to roles and not users. + If you create an IAM role in your AWS account with permissions to create an application, anyone who can assume the role can create an application. Your AWS account, to which the user belongs, owns the application resource. ## Managing Access to Resources A *permissions policy* describes who has access to what. The following section explains the available options for creating permissions policies. **Note** This section discusses using IAM in the context of . It doesn't provide detailed information about the IAM service. For complete IAM documentation, see [What Is IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) in the *IAM User Guide*. For information about IAM policy syntax and descriptions, see [IAM JSON Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*. Policies that are attached to an IAM identity are referred to as *identity-based* policies (IAM policies). Policies that are attached to a resource are referred to as *resource-based* policies. supports only identity-based policies (IAM policies). **Topics** + [Identity-Based Policies (IAM Policies)](#manage-access-iam-policies) + [Resource-Based Policies](#manage-access-resource-policies) ### Identity-Based Policies (IAM Policies) You can attach policies to IAM identities. For example, you can do the following: + **Attach a permissions policy to a user or a group in your account** – To grant a user permissions to create an resource, such as an application, you can attach a permissions policy to a user or group that the user belongs to. + **Attach a permissions policy to a role (grant cross-account permissions)** – You can attach an identity-based permissions policy to an IAM role to grant cross-account permissions. For example, the administrator in account A can create a role to grant cross-account permissions to another AWS account (for example, account B) or an Amazon service as follows: 1. Account A administrator creates an IAM role and attaches a permissions policy to the role that grants permissions on resources in account A. 1. Account A administrator attaches a trust policy to the role identifying account B as the principal who can assume the role. 1. Account B administrator can then delegate permissions to assume the role to any users in account B. Doing this allows users in account B to create or access resources in account A. The principal in the trust policy can also be an Amazon service principal if you want to grant an Amazon service permissions to assume the role. For more information about using IAM to delegate permissions, see [Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) in the *IAM User Guide*. The following is an example policy that grants permission for the `kinesisanalytics:CreateApplication `action, which is required to create an application. **Note** This is an introductory example policy. When you attach the policy to the user, the user will be able to create an application using the AWS CLI or AWS SDK. But the user will need more permissions to configure input and output. In addition, the user will need more permissions when using the console. The later sections provide more information. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Stmt1473028104000", "Effect": "Allow", "Action": [ "kinesisanalytics:CreateApplication" ], "Resource": [ "*" ] } ] } ``` ------ For more information about using identity-based policies with , see [Using Identity-Based Policies (IAM Policies) for](using-identity-based-policies.md). For more information about users, groups, roles, and permissions, see [Identities (Users, Groups, and Roles)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) in the *IAM User Guide*. ### Resource-Based Policies Other services, such as Amazon S3, also support resource-based permissions policies. For example, you can attach a policy to an S3 bucket to manage access permissions to that bucket. doesn't support resource-based policies. ## Specifying Policy Elements: Actions, Effects, and Principals For each resource, the service defines a set of API operations. To grant permissions for these API operations, defines a set of actions that you can specify in a policy. Some API operations can require permissions for more than one action in order to perform the API operation. For more information about resources and API operations, see [Resources and Operations](#access-control-resources) and [Actions](API_Operations.md). The following are the most basic policy elements: + **Resource** – You use an Amazon Resource Name (ARN) to identify the resource that the policy applies to. For more information, see [Resources and Operations](#access-control-resources). + **Action** – You use action keywords to identify resource operations that you want to allow or deny. For example, you can use `create` to allow users to create an application. + **Effect** – You specify the effect, either allow or deny, when the user requests the specific action. If you don't explicitly grant access to (allow) a resource, access is implicitly denied. You can also explicitly deny access to a resource, which you might do to make sure that a user cannot access it, even if a different policy grants access. + **Principal** – In identity-based policies (IAM policies), the user that the policy is attached to is the implicit principal. For resource-based policies, you specify the user, account, service, or other entity that you want to receive permissions (applies to resource-based policies only). doesn't support resource-based policies. To learn more about IAM policy syntax and descriptions, see [IAM JSON Policy Reference](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) in the *IAM User Guide*. For a table showing all of the API operations and the resources that they apply to, see [API Permissions: Actions, Permissions, and Resources Reference](api-permissions-reference.md). ## Specifying Conditions in a Policy When you grant permissions, you can use the access policy language to specify the conditions when a policy should take effect. For example, you might want a policy to be applied only after a specific date. For more information about specifying conditions in a policy language, see [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition) in the *IAM User Guide*. To express conditions, you use predefined condition keys. There are no condition keys specific to . However, there are AWS-wide condition keys that you can use as appropriate. For a complete list of AWS-wide keys, see [Available Keys for Conditions](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) in the *IAM User Guide*. # Using Identity-Based Policies (IAM Policies) for The following are examples of identity-based policies that demonstrate how an account administrator can attach permissions policies to IAM identities (that is, users, groups, and roles) and grant permissions to perform operations on resources. **Important** We recommend that you first review the introductory topics that explain the basic concepts and options available to manage access to your resources. For more information, see [Overview of Managing Access Permissions to Your Resources](access-control-overview.md). **Topics** + [Permissions Required to Use the Console](#console-permissions) + [Amazon-Managed (Predefined) Policies for](#access-policy-aws-managed-policies) + [Customer Managed Policy Examples](#access-policy-customer-managed-examples) The following shows an example of a permissions policy. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Stmt1473028104000", "Effect": "Allow", "Action": [ "kinesisanalytics:CreateApplication" ], "Resource": [ "*" ] } ] } ``` ------ The policy has one statement: + The first statement grants permissions for one action (`kinesisanalytics:CreateApplication`) on a resource using the Amazon Resource Name (ARN) for the application. The ARN in this case specifies a wildcard character (\$1) to indicate that the permission is granted for any resource. For a table showing all of the API operations and the resources that they apply to, see [API Permissions: Actions, Permissions, and Resources Reference](api-permissions-reference.md). ## Permissions Required to Use the Console For a user to work with the console, you must grant the necessary permissions. For example, if you want a user to have permissions to create an application, grant permissions that show them the streaming sources in the account so that the user can configure input and output on the console. We recommend the following: + Use the Amazon-managed policies to grant user permissions. For available policies, see [Amazon-Managed (Predefined) Policies for](#access-policy-aws-managed-policies). + Create custom policies. In this case, we recommend that you review the example provided in this section. For more information, see [Customer Managed Policy Examples](#access-policy-customer-managed-examples). ## Amazon-Managed (Predefined) Policies for AWS addresses many common use cases by providing standalone IAM policies that are created and administered by AWS. These Amazon-managed policies grant necessary permissions for common use cases so that you can avoid having to investigate what permissions are needed. For more information, see [Amazon-Managed Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) in the *IAM User Guide*. The following Amazon-managed policies, which you can attach to users in your account, are specific to : + **`AmazonKinesisAnalyticsReadOnly`** – Grants permissions for actions that enable a user to list applications and review input/output configuration. It also grants permissions that allow a user to view a list of Kinesis streams and Firehose delivery streams. As the application is running, the user can view source data and real-time analytics results in the console.   + **`AmazonKinesisAnalyticsFullAccess`** – Grants permissions for all actions and all other permissions that allows a user to create and manage applications. However, note the following:   + These permissions are not sufficient if the user wants to create a new IAM role in the console (these permissions allow the user to select an existing role). If you want the user to be able to create an IAM role in the console, add the `IAMFullAccess` Amazon-managed policy.   + A user must have permission for the `iam:PassRole` action to specify an IAM role when configuring application. This Amazon-managed policy grants permission for the `iam:PassRole` action to the user only on the IAM roles that start with the prefix `service-role/kinesis-analytics`. If the user wants to configure the application with a role that does not have this prefix, you first must explicitly grant the user permission for the `iam:PassRole` action on the specific role. You can also create your own custom IAM policies to allow permissions for actions and resources. You can attach these custom policies to the users or groups that require those permissions. ## Customer Managed Policy Examples The examples in this section provide a group of sample policies that you can attach to a user. If you are new to creating policies, we recommend that you first create a user in your account. Then attach the policies to the user in sequence, as outlined in the steps in this section. You can then use the console to verify the effects of each policy as you attach the policy to the user. Initially, the user doesn't have permissions and can't do anything on the console. As you attach policies to the user, you can verify that the user can perform various actions on the console.  We recommend that you use two browser windows. In one window, create the user and grant permissions. In the other, sign in to the AWS Management Console using the user's credentials and verify permissions as you grant them. For examples that show how to create an IAM role that you can use as an execution role for your application, see [Creating IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) in the *IAM User Guide*. **Topics** + [Step 1: Create an IAM User](#console-permissions-createuser) + [Step 2: Allow the User Permissions for Actions that Are Not Specific to](#console-permissions-grant-non-ka-permissions) + [Step 3: Allow the User to View a List of Applications and View Details](#console-permissions-grant-list-applications) + [Step 4: Allow the User to Start a Specific Application](#console-permissions-start-app) + [Step 5: Allow the User to Create an Application](#console-permissions-grant-create-applications) + [Step 6: Allow the Application to Use Lambda Preprocessing](#console-permissions-grant-lambda) ### Step 1: Create an IAM User First, you need to create a user, add the user to an IAM group with administrative permissions, and then grant administrative permissions to the user that you created. You can then access AWS using a special URL and that user's credentials. For instructions, see [Creating Your First IAM User and Administrators Group](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) in the *IAM User Guide*. ### Step 2: Allow the User Permissions for Actions that Are Not Specific to First, grant a user permission for all actions that aren't specific to that the user will need when working with applications. These include permissions for working with streams (Amazon Kinesis Data Streams actions, Amazon Data Firehose actions), and permissions for CloudWatch actions. Attach the following policy to the user. You need to update the policy by providing an IAM role name for which you want to grant the `iam:PassRole` permission, or specify a wildcard character (\$1) indicating all IAM roles. This is not a secure practice; however you might not have a specific IAM role created during this testing. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesis:CreateStream", "kinesis:DeleteStream", "kinesis:DescribeStream", "kinesis:ListStreams", "kinesis:PutRecord", "kinesis:PutRecords" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "firehose:DescribeDeliveryStream", "firehose:ListDeliveryStreams" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics" ], "Resource": "*" }, { "Effect": "Allow", "Action": "logs:GetLogEvents", "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:ListPolicyVersions", "iam:ListRoles" ], "Resource": "*" }, { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::*:role/service-role/role-name" } ] } ``` ------ ### Step 3: Allow the User to View a List of Applications and View Details The following policy grants a user the following permissions: + Permission for the `kinesisanalytics:ListApplications` action so the user can view a list of applications. This is a service-level API call, and therefore you specify "\$1" as the `Resource` value. + Permission for the `kinesisanalytics:DescribeApplication` action so that you can get information about any of the applications. Add this policy to the user. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesisanalytics:ListApplications" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "kinesisanalytics:DescribeApplication" ], "Resource": "arn:aws:kinesisanalytics:us-east-1:123456789012:application/*" } ] } ``` ------ Verify these permissions by signing into the console using the user credentials. ### Step 4: Allow the User to Start a Specific Application If you want the user to be able to start one of the existing applications, attach the following policy to the user. The policy provides the permission for the `kinesisanalytics:StartApplication` action. You must update the policy by providing your account ID, AWS Region and application name. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kinesisanalytics:StartApplication" ], "Resource": "arn:aws:kinesisanalytics:us-east-1:123456789012:application/application-name" } ] } ``` ------ ### Step 5: Allow the User to Create an Application If you want the user to create an application, you can then attach the following policy to the user. You must update the policy and provide an AWS Region, your account ID, and either a specific application name that you want the user to create, or a "\$1" so that the user can specify any application name (and thus create multiple applications). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "Stmt1473028104000", "Effect": "Allow", "Action": [ "kinesisanalytics:CreateApplication" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "kinesisanalytics:StartApplication", "kinesisanalytics:UpdateApplication", "kinesisanalytics:AddApplicationInput", "kinesisanalytics:AddApplicationOutput" ], "Resource": "arn:aws:kinesisanalytics:us-east-1:123456789012:application/application-name" } ] } ``` ------ ### Step 6: Allow the Application to Use Lambda Preprocessing If you want the application to be able to use Lambda preprocessing, attach the following policy to the role. ``` { "Sid": "UseLambdaFunction", "Effect": "Allow", "Action": [ "lambda:InvokeFunction", "lambda:GetFunctionConfiguration" ], "Resource": "" } ``` # API Permissions: Actions, Permissions, and Resources Reference When you are setting up [Access Control](authentication-and-access-control.md#access-control) and writing a permissions policy that you can attach to an IAM identity (identity-based policies), you can use the following table as a reference. The table lists each API operation, the corresponding actions for which you can grant permissions to perform the action, and the AWS resource for which you can grant the permissions. You specify the actions in the policy's `Action` field, and you specify the resource value in the policy's `Resource` field. You can use AWS-wide condition keys in your policies to express conditions. For a complete list of AWS-wide keys, see [Available Keys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#AvailableKeys) in the *IAM User Guide*. **Note** To specify an action, use the `kinesisanalytics` prefix followed by the API operation name (for example, `kinesisanalytics:AddApplicationInput`). Use the scroll bars to see the rest of the table. **API and Required Permissions for Actions** | API Operations | Required Permissions (API Actions) | Resources | | --- | --- | --- | | [AddApplicationInput](API_AddApplicationInput.md) | kinesisanalytics:AddApplicationInput | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [AddApplicationOutput](API_AddApplicationOutput.md) | kinesisanalytics:AddApplicationOutput | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [AddApplicationReferenceDataSource](API_AddApplicationReferenceDataSource.md) | kinesisanalytics:AddApplicationReferenceDataSource | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [CreateApplication](API_CreateApplication.md) | kinesisanalytics:CreateApplication | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [DeleteApplication](API_DeleteApplication.md) | kinesisanalytics:DeleteApplication | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [DeleteApplicationOutput](API_DeleteApplicationOutput.md) | kinesisanalytics:DeleteApplicationOutput | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [DeleteApplicationReferenceDataSource](API_DeleteApplicationReferenceDataSource.md) | kinesisanalytics:DeleteApplicationReferenceDataSource | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [DescribeApplication](API_DescribeApplication.md) | kinesisanalytics:DescribeApplication | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [DiscoverInputSchema](API_DiscoverInputSchema.md) | kinesisanalytics:DiscoverInputSchema | \$1 | | [ListApplications](API_ListApplications.md) | kinesisanalytics:ListApplications | \$1 | | [StartApplication](API_StartApplication.md) | kinesisanalytics:StartApplication | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [StopApplication](API_StopApplication.md) | kinesisanalytics:StopApplication | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | [UpdateApplication](API_UpdateApplication.md) | kinesisanalytics:UpdateApplication | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | | Access or sample data in the console | kinesisanalytics:GetApplicationState | `arn:aws:kinesisanalytics: region:accountId:application/application-name` | ## GetApplicationState The console uses an internal method called `GetApplicationState` to sample or access application data. Your service application needs to have permissions for the internal `kinesisanalytics:GetApplicationState` API to sample or access application data through the AWS Management Console. # Monitoring Amazon Kinesis Data Analytics Kinesis Data Analytics provides monitoring functionality for your applications. For more information, see [Monitoring for SQL Applications](monitoring-overview.md). # Compliance Validation for Amazon Kinesis Data Analytics for SQL Applications Third-party auditors assess the security and compliance of Amazon Kinesis Data Analytics as part of multiple AWS compliance programs. These include SOC, PCI, HIPAA, and others. For a list of AWS services in scope of specific compliance programs, see [Amazon Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/). For general information, see [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/). You can download third-party audit reports using AWS Artifact. For more information, see [Downloading Reports in AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html). Your compliance responsibility when using Kinesis Data Analytics is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. If your use of Kinesis Data Analytics is subject to compliance with standards such as HIPAA or PCI, AWS provides resources to help: + [Security and Compliance Quick Start Guides](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – These deployment guides discuss architectural considerations and provide steps for deploying security- and compliance-focused baseline environments on AWS. + [Architecting for HIPAA Security and Compliance Whitepaper ](https://d0.awsstatic.com/whitepapers/compliance/AWS_HIPAA_Compliance_Whitepaper.pdf) – This whitepaper describes how companies can use AWS to create HIPAA-compliant applications. + [AWS Compliance Resources](https://aws.amazon.com/compliance/resources/) – This collection of workbooks and guides might apply to your industry and location. + [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) – This AWS service assesses how well your resource configurations comply with internal practices, industry guidelines, and regulations. + [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) – This AWS service provides a comprehensive view of your security state within AWS that helps you check your compliance with security industry standards and best practices. # Resilience in Amazon Kinesis Data Analytics The AWS global infrastructure is built around AWS Regions and Availability Zones. AWS Regions provide multiple physically separated and isolated Availability Zones, which are connected with low-latency, high-throughput, and highly redundant networking. With Availability Zones, you can design and operate applications and databases that automatically fail over between Availability Zones without interruption. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures. For more information about AWS Regions and Availability Zones, see [AWS Global Infrastructure](https://aws.amazon.com/about-aws/global-infrastructure/). In addition to the AWS global infrastructure, Kinesis Data Analytics offers several features to help support your data resiliency and backup needs. ## Disaster Recovery Kinesis Data Analytics runs in a serverless mode, and takes care of host degradations, Availability Zone availability, and other infrastructure related issues by performing automatic migration. When this happens, Kinesis Data Analytics ensures that the application is processed without any loss of data. For more information, see [Delivery Model for Persisting Application Output to an External Destination](failover-checkpoint.md). # Infrastructure Security in Kinesis Data Analytics for SQL Applications As a managed service, Amazon Kinesis Data Analytics is protected by the AWS global network security procedures that are described in the [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) whitepaper. You use AWS published API calls to access Kinesis Data Analytics through the network. Clients must support Transport Layer Security (TLS) 1.2 or later. Clients must also support cipher suites with perfect forward secrecy (PFS) such as Ephemeral Diffie-Hellman (DHE) or Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Most modern systems such as Java 7 and later support these modes. Additionally, requests must be signed by using an access key ID and a secret access key that is associated with an IAM principal. Or you can use the [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) to generate temporary security credentials to sign requests. # Security Best Practices for Kinesis Data Analytics Amazon Kinesis Data Analytics provides a number of security features to consider as you develop and implement your own security policies. The following best practices are general guidelines and don’t represent a complete security solution. Because these best practices might not be appropriate or sufficient for your environment, treat them as helpful considerations rather than prescriptions. ## Use IAM roles to access other Amazon services Your Kinesis Data Analytics application must have valid credentials to access resources in other services, such as Kinesis data streams, Firehose delivery streams, or Amazon S3 buckets. You should not store AWS credentials directly in the application or in an Amazon S3 bucket. These are long-term credentials that are not automatically rotated and could have a significant business impact if they are compromised. Instead, you should use an IAM role to manage temporary credentials for your application to access other resources. When you use a role, you don't have to use long-term credentials to access other resources. For more information, see the following topics in the *IAM User Guide*: + [IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) + [Common Scenarios for Roles: Users, Applications, and Services](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios.html) ## Implement Server-Side Encryption in Dependent Resources Data at rest and data in transit is encrypted in Kinesis Data Analytics, and this encryption cannot be disabled. You should implement server-side encryption in your dependent resources, such as Kinesis data streams, Firehose delivery streams, and Amazon S3 buckets. For more information on implementing server-side encryption in dependent resources, see [Data Protection](data-protection.md). ## Use CloudTrail to Monitor API Calls Kinesis Data Analytics is integrated with AWS CloudTrail, a service that provides a record of actions taken by a user, role, or an Amazon service in Kinesis Data Analytics. Using the information collected by CloudTrail, you can determine the request that was made to Kinesis Data Analytics, the IP address from which the request was made, who made the request, when it was made, and additional details. For more information, see [Logging API Calls with AWS CloudTrail](logging-using-cloudtrail.md).