InvalidClientTokenId sending message to SQS that works for SES

0

I'm having trouble sending a message to a new SQS queue and receive this error: [Type] => Sender [Code] => InvalidClientTokenId [Message] => The AWS Access Key Id you provided does not exist in our records.

Any suggestions on why SQS is not recognizing the Key ID for SQS SendMessage, but does accept it for SES calls?

  • Key Id is the identical key used for successfully sending SES mail
  • Same Elasticbeanstalk instance, application, AWS SDK.
  • PHP 7.4 64 bit
  • Elasticbeanstalk instance on Amazon Linux 2/3.3.9
  • AWS SDK 1.5.14 (tried 3.x, same results)

Php code: require_once(<path>/aws-sdk/sdk.class.php'); require_once(<path>/aws-sdk/services/sqs.class.php');

$options = array('key' => 'AKIAblahblahblah','secret' => 'blahblahblahblahblahblahblahblahblahblahblahblah');
$sqs = new AmazonSQS($options);
$sqs->set_region('sqs.us-east-2.amazonaws.com');
$sqs_queue = 'https://sqs.us-east-2.amazonaws.com/111112345678/my-app-sa';

$message = 'test';

$r = $sqs->send_message($sqs_queue, $message);

Elasticbeanstalk:

IAM instance profile: aws-elasticbeanstalk-ec2-role Service role: arn:aws:iam::111112345678:role/aws-elasticbeanstalk-service-role

IAM User: Name=my-app-sa User ARN=arn:aws:iam::111112345678:user/my-app-sa Permissions: Policy=AmazonSQSFullAccess Created AccessKey: keyID=AKIAblahblahblah

SQS Queue: Name=my-sqs-queue Access Policy: { "Version": "2008-10-17", "Id": "__default_policy_ID", "Statement": [ { "Sid": "__owner_statement", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111112345678:root" }, "Action": "SQS:*", "Resource": "arn:aws:sqs:us-east-2:111112345678:my-sqs-queue" }, { "Sid": "__sender_statement", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111112345678:role/aws-elasticbeanstalk-ec2-role", "arn:aws:iam::111112345678:user/my-app-sa", "arn:aws:iam::111112345678:role/aws-elasticbeanstalk-service-role" ] }, "Action": "SQS:SendMessage", "Resource": "arn:aws:sqs:us-east-2:111112345678:my-sqs-queue" }, { "Sid": "__receiver_statement", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws:iam::111112345678:role/aws-elasticbeanstalk-ec2-role", "arn:aws:iam::111112345678:user/my-app-sa", "arn:aws:iam::111112345678:role/aws-elasticbeanstalk-service-role" ] }, "Action": [ "SQS:ChangeMessageVisibility", "SQS:DeleteMessage", "SQS:ReceiveMessage" ], "Resource": "arn:aws:sqs:us-east-2:111112345678:my-sqs-queue" } ] }

2 Answers
0

Probably one of your calls (SES) is working using temporary credentials from instance profile and not the hardcoded credentials? To narrow down this you can try to run some commands using those credentials from local CLI to see if they are accepted or no. BTW it's a good practice to use temp credentials from instance profile instead of putting credentials inside your code, so probably you can re-write your app to use that (if you use AWS PHP SDK that is very simple).

answered 2 years ago
  • Thank you for your response. I dumped the Credentials object following the 'set_region' call for both the SQS and SES routines. It appears they are both using keyid , not the temp credentials. Only using hardcoded creds for this POC, will use more secure method later. SQS api_version:2011-10-01 SQS auth_class:AuthV2Query SQS credentials: default_cache_config => certificate_authority =>false key => AKIAblahblah secret => blahblah

    SES api_version:2010-12-01 SES auth_class:AuthV4Query SES credentials: default_cache_config => certificate_authority =>false key => AKIAblahblah secret => blahblah

  • I agree with using temp credentials from instance profile. Tried it briefly, but got this error: "No credentials were provided. The SDK attempted to retrieve Instance Profile credentials from the EC2 Instance Metadata Service, but failed to do so. Instance profile credentials are only accessible on EC2 instances configured with a specific IAM role."

    I have the Elasticbeanstalk environment set to: IAM instance profile: aws-elasticbeanstalk-ec2-role Service role: arn:aws:iam::111112345678:role/aws-elasticbeanstalk-service-role

0

For sure there is something wrong with the credentials. Please check this article.

It's hard to tell more without seeing the code, but it looks like there is something different in access keys for SES and SQS. I think you should debug it and check if it's properly passed to the SQS client.

profile picture
MG
answered 2 years ago
  • Thank you for your response. I dumped the Credentials object following the 'set_region' call for both the SQS and SES routines. They appeared identical. Interesting that the SQS & SES return different values for api version and auth class. SQS api_version:2011-10-01 SQS auth_class:AuthV2Query SQS credentials: [default_cache_config] => [certificate_authority] =>false [key] => AKIAblahblah [secret] => blahblah

    SES api_version:2010-12-01 SES auth_class:AuthV4Query SES credentials: [default_cache_config] => [certificate_authority] =>false [key] => AKIAblahblahblah [secret] => blahblah

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions