ConstructionFailure(MissingCredentials) when using IAM Roles attached to an instance
#606
Assignees
Labels
bug
This issue is a bug.
Comments
albx79
added
bug
|
I believe this issue is the same one as #425 The required dependencies: [dependencies]
aws-sdk-sqs = "0.17.0"
aws-smithy-client = "0.47.0"
aws-sig-auth = "0.47.0"
aws-smithy-http = "0.47.0"
aws-config = "0.47.0"
tokio = { version = "1.20.1", features = ["full"] }The code: use aws_sdk_sqs::operation::GetQueueUrl;
use aws_sdk_sqs::Credentials;
use aws_sig_auth::signer::OperationSigningConfig;
use aws_sig_auth::signer::SigningRequirements;
use aws_smithy_http::operation::Operation;
#[tokio::main]
async fn main() {
let conf = aws_config::from_env()
.credentials_provider(Credentials::new("stub", "stub", None, None, "faked"))
.region("us-east-1")
.load()
.await;
let conf = aws_sdk_sqs::Config::new(&conf);
let client = aws_smithy_client::Builder::dyn_https()
.middleware(aws_sdk_sqs::middleware::DefaultMiddleware::new())
.build();
let mut operation = GetQueueUrl::builder()
.queue_name("foo_queue")
.build()
.unwrap()
.make_operation(&conf)
.await
.unwrap();
make_unsigned(&mut operation);
let resp = client
.call(operation)
.await
.expect("request should succeed");
println!("{}", resp.queue_url().unwrap_or_default());
}
// this function will work on any S3 operation
fn make_unsigned<I, R>(operation: &mut Operation<I, R>) {
let mut props = operation.properties_mut();
let mut signing_config = props
.get_mut::<OperationSigningConfig>()
.expect("has signing_config");
signing_config.signing_requirements = SigningRequirements::Disabled;
}🤞 |
Velfi
added
the
response-requested
Velfi
changed the title
ConstructionFailure(MissingCredentials) when using IAM Roles attached to an instance
|
(It could also be that our |
github-actions
bot
removed
the
response-requested
|
@Velfi I can confirm that your workaround works. Thanks for the quick reply, I'll close this issue. |
|
Sorry, I need to reopen this because I realized that, while the workaround prevents the client-side error and allows me to make the HTTP call to receive-messages, I'm now getting an Access Denied error from AWS. I'll put some log lines here: The same operation, in the same environment, using the CLI, works correctly. |
|
Can you use debug information to ensure you're hitting the same region and resolving the same credentials in the CLI and the Rust SDK? It appears to be dispatching the request successfully Seems like you're using the receive_message API here based on the logs? Please send the CLI command your invoking along side the Rust code |
|
This is the CLI command:
The logs are a bit verbose, but we can already see that I'm hitting the correct URL/endpoint: QueueUrl=https://sqs.eu-west-1.amazonaws.com/087849981844/excalibur-company-materializer-qrp-events I'm not sure how to find out what credentials it's resolving. My understanding is that I'm not sending any credentials, and indeed I can't find any in the logs, but my knowledge of AWS credentials is still a bit sketchy. |
|
@albx79 Would you be able to send us a minimum reproduction of what you're doing in your Rust code? |
|
Hi, here's the minimal example: fn make_unsigned<I, R>(op: &mut Operation<I, R>) {
let mut props = op.properties_mut();
let mut signing_config = props
.get_mut::<OperationSigningConfig>()
.expect("has signing_config");
signing_config.signing_requirements = SigningRequirements::Disabled;
}
#[tokio::main]
async fn main() -> () {
let client = aws_smithy_client::Builder::dyn_https()
.middleware(aws_sdk_sqs::middleware::DefaultMiddleware::new())
.build();
let conf = aws_config::from_env()
.credentials_provider(aws_types::Credentials::new("stub", "stub", None, None, "faked"))
.load()
.await;
let conf = aws_sdk_sqs::config::Builder::from(&conf).build();
let mut rcv_msg_op = aws_sdk_sqs::operation::ReceiveMessage::builder()
.queue_url("https://sqs.eu-west-1.amazonaws.com/087849981844/excalibur-company-materializer-qrp-events")
.build().unwrap()
.make_operation(&conf)
.await.unwrap();
make_unsigned(&mut rcv_msg_op);
client.call(rcv_msg_op).await.unwrap();
}And this is the output I get: Thanks! |
|
I finally got a k8s test environment set up and I'm looking into this. |
|
Hey @albx70, after looking at this, I wasn't able to repro your issue so I have something for you to try (if you wouldn't mind.) // [dependencies]
// aws-config = "0.47.0"
// aws-sdk-sqs = "0.17.0"
// aws-sdk-sts = "0.17.0"
// tokio = { version = "1.20.1", features = ["full"] }
// tracing = "0.1.36"
// tracing-subscriber = "0.3.15"
#[tokio::main]
async fn main() {
tracing_subscriber::fmt::init();
let conf = aws_config::load_from_env().await;
{
let client = aws_sdk_sts::Client::new(&conf);
let res = client.get_caller_identity().send().await;
tracing::info!("caller_identity = {:#?}", res)
}
let queue_name = std::env::var("SQS_QUEUE_NAME").unwrap();
let client = aws_sdk_sqs::Client::new(&conf);
let res = client
.get_queue_url()
.queue_name(queue_name)
.send()
.await
.unwrap();
let queue_url = res.queue_url().unwrap();
let res = client.receive_message().queue_url(queue_url).send().await;
match res {
Ok(res) => tracing::info!("success: {:#?}", res),
Err(e) => tracing::error!("failure: {:#?}", e),
}
}Run this like so: That will emit a bunch of logs related to resolving your credentials and they'll look something like this: What I'm hoping is that we'll see that it's either not loading your creds OR it's loading the wrong creds. Also, this will log the output of |
|
I'm not sure what changed, but it's working now. Thanks for your help, and sorry for the inconvenience. |
|
|
Glad it's working! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
We are running an SQS client as a Kubernetes pod on EC2.
When doing any SQS request, we get the following error:
Error: ConstructionFailure(MissingCredentials)Expected Behavior
According to the documentation in https://docs.aws.amazon.com/sdk-for-rust/latest/dg/credentials.html, the request should work because "IAM Roles attached to an instance" is supported.
Current Behavior
We tested the EC2 policy using the AWS command line, and we were able to query the SQS queue without API keys.
We also have a number of services that access S3, and they also work correctly without API keys.
Reproduction Steps
I'm just building the client
and sending the request
Possible Solution
No response
Additional Information/Context
No response
Version
The text was updated successfully, but these errors were encountered: