- 最新
- 最多得票
- 最多評論
Hi,
Not sure if this is the problem, but here is my first guess..
If you currently have something like this:
const sQS = new SQSClient({ profile: 'default',
region: 'region'
});
You will need to change to this so that the application will pickup the credentials from the role instead of from the default profile:
const sQS = new SQSClient({ region: 'region' });
-randy
Hi RandyTakeshita,
Thank you very much for the response, yes we using same what you have suggested.
AmazonSQSClient client = new AmazonSQSClient('RegionEndpoint.APNortheast2');
Hi,
Can you please add the complete Access Denied message, along with the Roles/Policies/Trust Relationships currently used for SQS.
Thanks,
-randy
Sure,
Error:
Amazon.SQS.AmazonSQSException: The security token included in the request is invalid. ---> Amazon.Runtime.Internal.HttpErrorResponseException: The remote server returned an error: (403) Forbidden. ---> System.Net.WebException: The remote server returned an error: (403) Forbidden. at System.Net.HttpWebRequest.GetResponse() at Amazon.Runtime.Internal.HttpRequest.GetResponse() --- End of inner exception stack trace --- at Amazon.Runtime.Internal.HttpRequest.GetResponse() at Amazon.Runtime.Internal.HttpHandler1.InvokeSync(IExecutionContext executionContext) at Amazon.Runtime.Internal.Unmarshaller.InvokeSync(IExecutionContext executionContext) at Amazon.SQS.Internal.ValidationResponseHandler.InvokeSync(IExecutionContext executionContext) in E:\JenkinsWorkspaces\v3-stage-release\AWSDotNetPublic\sdk\src\Services\SQS\Custom\Internal\ValidationResponseHandler.cs:line 29 at Amazon.Runtime.Internal.ErrorHandler.InvokeSync(IExecutionContext executionContext) --- End of inner exception stack trace --- at Amazon.Runtime.Internal.HttpErrorResponseExceptionHandler.HandleException(IExecutionContext executionContext, HttpErrorResponseException exception) at Amazon.Runtime.Internal.ErrorHandler.ProcessException(IExecutionContext executionContext, Exception exception) at Amazon.Runtime.Internal.ErrorHandler.InvokeSync(IExecutionContext executionContext) at Amazon.Runtime.Internal.CallbackHandler.InvokeSync(IExecutionContext executionContext) at Amazon.Runtime.Internal.RetryHandler.InvokeSync(IExecutionContext executionContext) at Amazon.Runtime.Internal.CallbackHandler.InvokeSync(IExecutionContext executionContext) at Amazon.Runtime.Internal.CallbackHandler.InvokeSync(IExecutionContext executionContext) at Amazon.Runtime.Internal.ErrorCallbackHandler.InvokeSync(IExecutionContext executionContext) at Amazon.Runtime.Internal.MetricsHandler.InvokeSync(IExecutionContext executionContext) at Amazon.Runtime.Internal.RuntimePipeline.InvokeSync(IExecutionContext executionContext) at Amazon.Runtime.AmazonServiceClient.Invoke\[TRequest,TResponse](TRequest request, IMarshaller
2 marshaller, ResponseUnmarshaller unmarshaller) at Amazon.SQS.AmazonSQSClient.ReceiveMessage(ReceiveMessageRequest request) in E:\JenkinsWorkspaces\v3-stage-release\AWSDotNetPublic\sdk\src\Services\SQS\Generated_bcl45\AmazonSQSClient.cs:line 2371
Policy:
We gave full sqs access to policy we had linked on our aws ec2.
Hi,
My next guess is that you have credentials already defined on the EC2 instance (that do NOT have full permissions) that is taking precedence over the full permissions policy that has been given to EC2 (based on the Credential Provider Chain described below). Note roles/policy given to EC2 are the lowest precedence in the chain, so go through each of the steps below to see if something else is taking precedence.
https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html
When you initialize a new service client without supplying any arguments, the AWS SDK for Java attempts to find AWS credentials by using the default credential provider chain implemented by the DefaultAWSCredentialsProviderChain class. The default credential provider chain looks for credentials in this order:
Environment variables–AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY. The AWS SDK for Java uses the EnvironmentVariableCredentialsProvider class to load these credentials.
Java system properties–aws.accessKeyId and aws.secretKey. The AWS SDK for Java uses the SystemPropertiesCredentialsProvider to load these credentials.
The default credential profiles file– typically located at ~/.aws/credentials (location can vary per platform), and shared by many of the AWS SDKs and by the AWS CLI. The AWS SDK for Java uses the ProfileCredentialsProvider to load these credentials.
You can create a credentials file by using the aws configure command provided by the AWS CLI, or you can create it by editing the file with a text editor. For information about the credentials file format, see AWS Credentials File Format.
Amazon ECS container credentials– loaded from the Amazon ECS if the environment variable AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is set. The AWS SDK for Java uses the ContainerCredentialsProvider to load these credentials.
Instance profile credentials– used on EC2 instances, and delivered through the Amazon EC2 metadata service. The AWS SDK for Java uses the InstanceProfileCredentialsProvider to load these credentials.
Note
Instance profile credentials are used only if AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is not set. See EC2ContainerCredentialsProviderWrapper for more information.
-randy
Much Appreciated, This gave me some insight, make some question raising to myself. We have AWS CLI installed on it. Since it is production I will do some non-business hours and get back to you. Will keep you posting.
Edited by: Pruthvi on Sep 12, 2019 7:45 AM
Hi Yes, it helped, I think the issue is with AWS CLI since according to profile EC2 is looking in AWS CLI I have tested different cases and set the version to an IAM role. Thank you very much for your help.
相關內容
- 已提問 7 個月前
- AWS 官方已更新 2 年前
- AWS 官方已更新 2 年前