Setting Up Least Privilege Access for Your Encrypted Amazon SQS Queue

Amazon Simple Queue Service (Amazon SQS) is a fully-managed message queuing service that helps you decouple and scale microservices, distributed systems, and serverless applications. It provides robust authentication methods to control access to the queue while ensuring data security through encryption during transit via HTTP over SSL or TLS. Additionally, it supports server-side encryption using AWS Key Management Service (AWS KMS) to safeguard the data flowing through Amazon SQS. These features make Amazon SQS suitable for exchanging sensitive information between applications. With the integration of Amazon SQS and AWS KMS, you can centrally manage the keys protecting both SQS and your other AWS resources.

Various AWS services, such as Amazon Simple Storage Service (Amazon S3) and Amazon Simple Notification Service (Amazon SNS), can serve as event sources that send events to Amazon SQS. To allow an event source to access an encrypted SQS queue, you need to configure the queue with a customer-managed key in AWS KMS and adjust the key policy to permit the event source to utilize the necessary AWS KMS API methods. Additionally, the event source must have permissions to authenticate access to the queue for event transmission. This can be accomplished through an SQS policy, a resource-based policy that governs access to the SQS queue and its contents.

In this article, we will demonstrate how to manage access to your encrypted SQS queue using both the key policy and the SQS policy. The policies detailed here will help you achieve a least privilege access model. We will also explain how the resource-based policies outlined in this article can mitigate the confused deputy problem by leveraging the aws:SourceArn, aws:SourceAccount, and aws:PrincipalOrgID global AWS Identity and Access Management (IAM) condition context keys.

Solution Overview

To illustrate how to construct the key policy and the SQS queue policy, we will walk through a common use case, as shown in the accompanying diagram.

The use case consists of the following steps:

The message producer is an Amazon SNS topic, configured to dispatch messages to an encrypted Amazon SQS queue secured with a customer-managed AWS KMS key.
The message consumer can be a compute service such as an AWS Lambda function, an Amazon Elastic Compute Cloud (Amazon EC2) instance, or an AWS Fargate container, designed to process messages from the queue.
The SQS queue is set to route failed messages to a dead-letter queue (DLQ), allowing you to debug your application or messaging system by isolating unprocessed messages to understand why their processing failed.

Note: If the message consumer resides within an Amazon Virtual Private Cloud (Amazon VPC) and you wish to restrict message reception to that specific VPC, you should append the DenyReceivingIfNotThroughVPCE policy statement to your SQS queue policy.

The SQS policy discussed here does not facilitate the redriving of messages directly to either the same or a different SQS queue.

Prerequisites

This article includes only the necessary IAM permissions in the form of policy statements. To create the policy, you will need to incorporate the statements into your SQS policy or AWS KMS key policy. This guide does not cover the creation of the SQS queue or the AWS KMS key. Therefore, ensure you have completed the following steps:

Set up an SQS queue. For guidance, refer to the “Create a queue” section in the Amazon SQS documentation.
Create an AWS KMS key. For instructions, see the “Creating keys” section in the AWS KMS documentation.

Least-Privilege Key Policy for Amazon SQS

In this section, we will outline the essential least-privilege permissions required in AWS KMS for the customer-managed key utilized to encrypt your SQS queue. These permissions are designed to restrict access to only the intended entities while enforcing the least privilege principle. The key policy should include the following statements, which we will detail below:

Grant administrator permissions to the KMS key
Grant read-only access to the key metadata
Permit AWS KMS permissions for Amazon SNS to publish messages to the queue
Allow consumers to decrypt messages from the queue

Grant Administrator Permissions to the KMS Key

To create an AWS KMS key, you must provide AWS KMS administrator permissions to the IAM role used for deploying the KMS key. These permissions are defined in the AllowKeyAdminPermissions policy statement outlined below. When adding this statement to your key policy, ensure you replace <admin-role ARN> with the Amazon Resource Name (ARN) of the IAM role responsible for deploying or managing the KMS key.

{
  "Sid": "AllowKeyAdminPermissions",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "<admin-role ARN>"
    ]
  },
  "Action": [
    "kms:Create*",
    "kms:Describe*",
    "kms:Enable*",
    "kms:List*",
    "kms:Put*",
    "kms:Update*",
    "kms:Revoke*",
    "kms:Disable*",
    "kms:Get*",
    "kms:Delete*",
    "kms:TagResource",
    "kms:UntagResource",
    "kms:ScheduleKeyDeletion",
    "kms:CancelKeyDeletion"
  ],
  "Resource": "*"
}

Note: In a key policy, the Resource element must be set to “*”, indicating “this KMS key.” The asterisk (“*”) identifies the KMS key to which the policy is linked.

Grant Read-Only Access to the Key Metadata

To provide read-only access to your key metadata for other IAM roles, add the AllowReadAccessToKeyMetaData statement to your key policy. This grants the AWS account root user read-only rights to the key metadata, allowing an IAM principal in the account access to the key metadata when their identity-based policies include permissions such as kms:Describe*, kms:Get*, and kms:List*. Be sure to replace <account-ID> with your own details.

{
  "Sid": "AllowReadAccessToKeyMetaData",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "arn:aws:iam::<account-ID>:root"
    ]
  },
  "Action": [
    "kms:Describe*",
    "kms:Get*",
    "kms:List*"
  ],
  "Resource": "*"
}

Grant AWS KMS Permissions to Amazon SNS to Publish Messages to the Queue

To enable your SNS topic to publish messages to your encrypted SQS queue, include the AllowSNSToSendToSQS policy statement in your key policy. This statement grants Amazon SNS the necessary permissions to use the KMS key for publishing to your SQS queue. Remember to replace <account-id> with your own information.

Note: The Condition element restricts access to the SNS service within the same AWS account where the SNS topic is located.

{
  "Sid": "AllowSNSToSendToSQS",
  "Effect": "Allow",
  "Principal": {
    "Service": [
      "sns.amazonaws.com"
    ]
  },
  "Action": [
    "kms:GenerateDataKey",
    "kms:Decrypt"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:SourceAccount": "<account-id>"
    }
  }
}

For more detailed insights on this topic, consider reading this blog post, which offers additional guidance. You can also explore expert opinions at this source. For visual learners, this video is an excellent resource.

This post is brought to you from Amazon IXD – VGT2, located at 6401 E Howdy Wells Ave, Las Vegas, NV 89115.