Sdk fails with an error when default profile is missing in ~/.aws/config or ~/.aws/config file is missing

[tomkris]

Describe the bug

It looks like sdk is not handling gracefully case when ~/.aws/config is missing or when default profile is missing in the ~/.aws/config file. Even if there are credentials provided by the environment (in this case by container credentials provider).

Expected Behavior

sdk should pick up available credentials from the credentials chain even if there are issues with ~/.aws/config file, and execute request successfully.

Current Behavior

sdk fails with an error:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ConstructionFailure(CredentialsLoadingError(InvalidConfiguration { cause: "ProfileFile provider could not be built: profile `default` was not defined: could not find source profile default referenced from the root profile" }))'

Reproduction Steps

Steps to reproduce:

1. remove ~/.aws/config file
2. Provide environment credentials using container credentials provider using export AWS_CONTAINER_CREDENTIALS_FULL_URI=http://127.0.0.1:1234
3. run code that uses sdk, e.g.

use tokio::runtime::Runtime;

fn main() {
    let rt = Runtime::new().unwrap();

    rt.block_on(async {
        let config = aws_config::from_env().load().await;
        let client = aws_sdk_sts::Client::new(&config);

        let ret = client.get_caller_identity().send().await.unwrap();
        println!("{:?}", ret);
    })
}

Alternatively to step (1), instead of removing ~/.aws/config you can modify it to remove [default] profile, behavior will be the same.

Possible Solution

SDK should ignore issue with ~/.aws/config file, for example, same way as aws CLI does it or boto3

Additional Information/Context

AWS cli handles missing ~/.aws/config gracefully:

% AWS_CONTAINER_CREDENTIALS_FULL_URI=http://127.0.0.1:1234 \
    aws sts get-caller-identity
{
    "Account": "xxx", 
    "UserId": "xxx", 
    "Arn": "xxx"
}

boto3 handles same case gracefully:

import boto3

client = boto3.client('sts')
response = client.get_caller_identity()

print(response)

% AWS_CONTAINER_CREDENTIALS_FULL_URI=http://127.0.0.1:1234 \
    python3 ./hello.py
{'UserId': 'XXXX', 'Account': 'XXXX', 'Arn': 'XXXX', 'ResponseMetadata': {'RequestId': 'XXX', 'HTTPStatusCode': 200, 'HTTPHeaders': {'x-amzn-requestid': 'XXX', 'content-type': 'text/xml', 'content-length': '446', 'date': 'XXXX}, 'RetryAttempts': 0}}

Version

% cargo tree | grep aws- aws-sdk-bug v0.1.0 (/local/home/xxx/src/aws-sdk-bug) ├── aws-config v0.12.0 │ ├── aws-http v0.12.0 │ │ ├── aws-smithy-http v0.42.0 │ │ │ ├── aws-smithy-types v0.42.0 │ │ ├── aws-smithy-types v0.42.0 () │ │ ├── aws-types v0.12.0 │ │ │ ├── aws-smithy-async v0.42.0 │ │ │ ├── aws-smithy-client v0.42.0 │ │ │ │ ├── aws-smithy-async v0.42.0 () │ │ │ │ ├── aws-smithy-http v0.42.0 () │ │ │ │ ├── aws-smithy-http-tower v0.42.0 │ │ │ │ │ ├── aws-smithy-http v0.42.0 () │ │ │ │ ├── aws-smithy-types v0.42.0 () │ │ │ ├── aws-smithy-http v0.42.0 () │ │ │ ├── aws-smithy-types v0.42.0 () │ ├── aws-sdk-sso v0.12.0 │ │ ├── aws-endpoint v0.12.0 │ │ │ ├── aws-smithy-http v0.42.0 () │ │ │ ├── aws-types v0.12.0 () │ │ ├── aws-http v0.12.0 () │ │ ├── aws-sig-auth v0.12.0 │ │ │ ├── aws-sigv4 v0.12.0 │ │ │ │ ├── aws-smithy-http v0.42.0 () │ │ │ ├── aws-smithy-http v0.42.0 () │ │ │ ├── aws-types v0.12.0 () │ │ ├── aws-smithy-async v0.42.0 () │ │ ├── aws-smithy-client v0.42.0 () │ │ ├── aws-smithy-http v0.42.0 () │ │ ├── aws-smithy-http-tower v0.42.0 () │ │ ├── aws-smithy-json v0.42.0 │ │ │ └── aws-smithy-types v0.42.0 () │ │ ├── aws-smithy-types v0.42.0 () │ │ ├── aws-types v0.12.0 () │ ├── aws-sdk-sts v0.12.0 │ │ ├── aws-endpoint v0.12.0 () │ │ ├── aws-http v0.12.0 () │ │ ├── aws-sig-auth v0.12.0 () │ │ ├── aws-smithy-async v0.42.0 () │ │ ├── aws-smithy-client v0.42.0 () │ │ ├── aws-smithy-http v0.42.0 () │ │ ├── aws-smithy-http-tower v0.42.0 () │ │ ├── aws-smithy-query v0.42.0 │ │ │ ├── aws-smithy-types v0.42.0 () │ │ ├── aws-smithy-types v0.42.0 () │ │ ├── aws-smithy-xml v0.42.0 │ │ ├── aws-types v0.12.0 () │ ├── aws-smithy-async v0.42.0 () │ ├── aws-smithy-client v0.42.0 () │ ├── aws-smithy-http v0.42.0 () │ ├── aws-smithy-http-tower v0.42.0 () │ ├── aws-smithy-json v0.42.0 () │ ├── aws-smithy-types v0.42.0 () │ ├── aws-types v0.12.0 () ├── aws-sdk-sts v0.12.0 ()

Environment details (OS name and version, etc.)

Linux

Logs

No response

[Velfi]

Thanks for reporting this issue; We'll investigate. If you wouldn't mind, could you run your request with with trace logging enabled and post the logs?

[rcoh]

interesting—do you also have an ~/.aws/credentials file? The Rust SDK has behavior that a broken (eg. incorrectly configured) credentials provider will return an early error because this is usually the best thing for a user, however, we may need to revisit that. We'd also need to investigate how the other SDKs handle it

[rcoh]

probable fix here: smithy-lang/smithy-rs#1458

I relaxed the behavior when no profile is explicitly selected & no default profile is defined—without seeing your profile or having more debug info I can't be 100% sure that's the issue you're seeing but it seems likely

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.