15

I have an SQS queue set up in AWS. I can send and receive messages perfectly using the AWS CLI and my IAM credentials that I set up.

What I would like to do is consume messages from the queue using Camel, configured via Spring. I tried out this example as it is very clear-cut and to the point:

https://github.com/christian-posta/camel-sqs-example

However, I get the following exception:

com.amazonaws.AmazonServiceException: Status Code: 403, AWS Service: AmazonSQS, 
AWS Request ID: 115057f8-3c4f-5ec6-8fe9-18ea097b2730, AWS Error Code: 
InvalidClientTokenId, AWS Error Message: The security token included in the 
request is invalid.

Amazon provides the most unhelpful documentation:

InvalidClientTokenId

The X.509 certificate or AWS access key ID provided does not exist in our records.

HTTP Status Code: 403

I have double-checked that I am using the exact same IAM credentials as I used through the CLI and that IAM user has a policy allowing read/write access to the queue. I have also toyed around with sending the additional URL params accessKey, secretKey, amazonSQSEndpoint and region as documented by Camel.

Why is Amazon saying that the access key is invalid or doesn't exist in their records and how can I fix my request?

Community
  • 1
  • 1
tytk
  • 2,082
  • 3
  • 27
  • 39
  • 1
    Any luck resolving this? – rastko Sep 28 '17 at 09:18
  • Sorry this was a while ago and I did eventually figure it out. Should have updated this post. Don't remember exactly what the solution was but I DO remember that in addition to ReceiveMessage and DeleteMessage permissions, Camel also requires GetQueueUrl, ListQueues and ChangeMessageVisibility. That may have been the solution to this issue, or it could have been the solution to something completely different. Hope this helps. – tytk Jan 11 '18 at 19:13

2 Answers2

5

When faced with a situation like this, there are two ways to trouble shoot this.

Option 1: Check the credentials in the ~/.aws/credentials file, where there can be mistakes made in the access key and secret. The probability of getting this wrong is very less, but it could happen.

Option 2: Provide the IAM user with necessary permissions, and check whether the issue gets recreated. If it's your very own AWS account, do give AmazonSQSFullAccess and carry out your work. In this sense, you will not easily run into any permission issues. Also check this link, where it mentions the minimum set of permissions requires for a user to work with AWS SQS.

Since the status code of the response is 403 (forbidden), this definitely has to be something related to authorization. I know my answer is coming two years later, but I once faced with a similar issue, and this worked.

Keet Sugathadasa
  • 11,595
  • 6
  • 65
  • 80
2

My solution to this issue was to correctly configure ~/.aws/credentials file

Open a bash script and run

sudo nano ~/.aws/credentials

Under [default] insert your IAM access key id and secret access key id. Be sure that your IAM role has the permissions to use SQS.

For the AWS Educate account you must configure also aws_session_token in this file. Sign in on vocareum and under "Your AWS Account Status" you will find two buttons : Account details and AWS console. Click on Account details and near AWS CLI click on show. Copy the access, secret key id and aws session token in the credentials file under "default" and you are done.

An additional note : be sure to configure your local timezone correctly. On Debian :

sudo apt-get install ntp

sudo systemctl enable ntp

sudo systemctl start ntp

If your time and date is still incorrect, try :

dpkg-reconfigure tzdata

and then restart your machine

ale753
  • 21
  • 2