AWS kinesis-agent-windows documentation change
Summary
Added JSON policy examples and formatting improvements for IAM configurations. Updated service name references with backticks for clarity.
Security assessment
The changes add explicit JSON policy examples for IAM permissions related to various AWS services (Kinesis, Firehose, S3, CloudWatch Logs, EC2 tags). While these are security-related configurations, there's no evidence of addressing a specific vulnerability. The updates improve documentation clarity around security best practices.
Diff
diff --git a/kinesis-agent-windows/latest/userguide/sink-object-declarations.md b/kinesis-agent-windows/latest/userguide/sink-object-declarations.md index 4a276ba60..2f6569267 100644 --- a//kinesis-agent-windows/latest/userguide/sink-object-declarations.md +++ b//kinesis-agent-windows/latest/userguide/sink-object-declarations.md @@ -374 +374 @@ After creating the instance profile, you can associate it with any EC2 instances - * If Kinesis Agent for Windows executes on an EC2 host in one account, but the resources that are the target of the sink reside in a different account, you can create an IAM role for cross-account access. For more information, see [Tutorial: Delegate Access Across AWS Accounts Using IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html). After creating the cross-account role, specify the Amazon Resource Name (ARN) for the cross-account role as the value of the `RoleARN` key-value pair in the sink declaration. Kinesis Agent for Windows then attempts to assume the specified cross-account role when accessing AWS resources that are associated with the sink type for that sink. + * If Kinesis Agent for Windows executes on an EC2 host in one account, but the resources that are the target of the sink reside in a different account, you can create an IAM role for cross-account access. For more information, see [Tutorial: Delegate Access Across AWS accounts Using IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html). After creating the cross-account role, specify the Amazon Resource Name (ARN) for the cross-account role as the value of the `RoleARN` key-value pair in the sink declaration. Kinesis Agent for Windows then attempts to assume the specified cross-account role when accessing AWS resources that are associated with the sink type for that sink. @@ -388 +388 @@ This is the recommended approach for non-EC2 instances because credentials are s - * If it's acceptable to run the AWSKinesisTap service for Kinesis Agent for Windows under a specific user instead of the default system account, use the following process: + * If it's acceptable to run the `AWSKinesisTap` service for Kinesis Agent for Windows under a specific user instead of the default system account, use the following process: @@ -394 +394 @@ This is the recommended approach for non-EC2 instances because credentials are s - 3. Change the AWSKinesisTap service on each desktop or server so that it runs under a specific user rather than the default system account. + 3. Change the `AWSKinesisTap` service on each desktop or server so that it runs under a specific user rather than the default system account. @@ -402 +402 @@ This is the recommended approach for non-EC2 hosts that cannot be managed instan - * If it is required to run the AWSKinesisTap service for Kinesis Agent for Windows under the default system account, you must use a shared credential file. This is because the system account has no Windows user profile for enabling the SDK store. Shared credential files are not encrypted, so we do not recommend this approach. For information about how to use shared configuration files, see [Configuring AWS Credentials](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-config-creds.html) in the _AWS SDK for .NET_. If you use this approach, we recommend that you use NTFS encryption and restricted file access to the shared configuration file. Keys should be rotated by a management platform, and the shared configuration file must be updated when the key rotation occurs. + * If it is required to run the `AWSKinesisTap` service for Kinesis Agent for Windows under the default system account, you must use a shared credential file. This is because the system account has no Windows user profile for enabling the SDK store. Shared credential files are not encrypted, so we do not recommend this approach. For information about how to use shared configuration files, see [Configuring AWS Credentials](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/net-dg-config-creds.html) in the _AWS SDK for .NET_. If you use this approach, we recommend that you use NTFS encryption and restricted file access to the shared configuration file. Keys should be rotated by a management platform, and the shared configuration file must be updated when the key rotation occurs. @@ -414,0 +415,6 @@ Attach the appropriate policies that follow to the IAM user or role that Kinesis +JSON + + +**** + + @@ -435,0 +443,6 @@ To limit authorization to a specific Region, account, or stream name, replace th +JSON + + +**** + + @@ -456,0 +471,6 @@ To limit authorization to a specific Region, account, or delivery stream name, r +JSON + + +**** + + @@ -473,0 +495,6 @@ For more information, see [Overview of Managing Access Permissions to Your Cloud +JSON + + +**** + + @@ -501,0 +530,6 @@ To restrict access to a specific Region, account, log group, or log stream, repl +JSON + + +**** + + @@ -538,0 +574,6 @@ Using variable expansion with the `ec2tag` variable prefix requires the `ec2:Des +JSON + + +**** + +