1

I'm working on an application that moves files from an sftp server to an AWS S3 bucket using an SQS message queue. Currently, the application is working but the permission policies in the template don't match what I would expect.

The template.yaml for the 'producer' application looks like this:

          - Effect: "Allow"
            Action:
              - kms:Encrypt
              - kms:Decrypt
            Resource: "arn:aws:kms:${aws.region}:${aws.account}:key/${kms.key}"
          - Effect: "Allow"
            Action:
              - s3:GetObject
              - s3:ListBucket
              - s3:PutObject
            Resource:
              - arn:aws:s3:::${aws.prefix}.${environment}.${functionalArea.lowerCase}.${integrationId.lowerCase}/*
          - Effect: "Allow"
            Action:
              - sqs:SendMessage
              - sqs:SendMessageBatch
              - sqs:GetQueueUrl
            Resource: !ImportValue 'lambda-sftp-to-s3:${environment}:SftpToS3QueueArn'

The consumer application has the following permissions:

          - Effect: "Allow"
            Action:
              - kms:Encrypt
              - kms:Decrypt
              - kms:GenerateDataKey
            Resource: "arn:aws:kms:${aws.region}:${aws.account}:key/${kms.key}"
          - Effect: "Allow"
            Action:
              - sqs:GetQueueAttributes
              - sqs:ReceiveMessage
              - sqs:DeleteMessage
              - sqs:GetQueueUrl
            Resource:  !Join [':',['arn:aws:sqs:${aws.region}:${aws.account}',!Ref QueueName]]
          - Effect: "Allow"
            Action:
              - s3:GetObject
              - s3:PutObject
            Resource:
              - arn:aws:s3:::esint.${environment}.*
              - arn:aws:s3:::${aws.prefix}.${environment}.*

This setup is working. The message gets dispatched and the file gets moved from sftp to S3 as requested. However, according the this: https://repost.aws/knowledge-center/sqs-accessdenied-errors documentation the 'producer' is supposed to have the definition for the GenerateDataKey permission.

How is the application able to function correctly with the permissions 'reversed' like this? Are there any pitfalls or potential problems with this arrangement I need to be aware of?

1 Answer 1

1

SQS uses envelope encryption, so the producer needs kms:GenerateDataKey to create a data key to encrypt the messages it sends, and it needs kms:Decrypt to verify the data key's integrity. It doesn't need kms:Encrypt, because it uses the data key to do the encryption.

The consumer just needs kms:Decrypt to decrypt the encrypted data key and then it can decrypt the messages using that data key.

So the repost doc is correct.

How is the application able to function correctly with the permissions 'reversed' like this?

My guess would be that either your queue isn't set up for SSE-KMS encryption, or your KMS key has the necessary permissions defined in it's key policy.

Are there any pitfalls or potential problems with this arrangement I need to be aware of?

Assuming the queue is encrypted, then you've got duplicate permissions defined in different places which isn't ideal, and you've got permissions defined that you don't need (e.g. neither producer nor consumer need kms:Encrypt).

Sign up to request clarification or add additional context in comments.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.