Add AWS Process Credential Resolver

[jonathan343]

Overview

This PR adds AWS process-based credential support to smithy-aws-core. It introduces a ProcessCredentialsResolver that sources credentials from an external command, and wires it into the default AWS identity chain so that a profile's credential_process setting is automatically honored. It also handles the common failure modes and caching behavior expected for both long-lived and temporary credentials.

Testing

Note

This was tested with internal AWS process tools for sourcing credentials. TODO: Test with popular external tools.

The identity chain is currently opt-in. We'll construct one and set it as the config's credentials resolver. Once set, credentials sourced from a credential_process profile are resolved through the chain:

# ~/.aws/config
[default]
credential_process = <insert command here>

Example Script:

import asyncio

from aws_sdk_bedrock_runtime.client import AsyncBedrockRuntimeClient
from aws_sdk_bedrock_runtime.config import Config
from aws_sdk_bedrock_runtime.models import (
    ContentBlockText,
    ConverseInput,
    Message,
)
from smithy_aws_core.identity import AWSCredentialsIdentity, IdentityChain


async def main():
    identity_chain = await IdentityChain.create(AWSCredentialsIdentity)
    client = AsyncBedrockRuntimeClient(
        config=Config(
            region="us-west-2",
            aws_credentials_identity_resolver=identity_chain,
        )
    )
    input_message = Message(
        role="user", content=[ContentBlockText(value="What is boto3?")]
    )
    response = await client.converse(
        ConverseInput(
            model_id="global.amazon.nova-2-lite-v1:0", messages=[input_message]
        )
    )

    output_message = response.output
    print(output_message)


asyncio.run(main())

The resolver can also be used directly, bypassing the chain and profile configuration entirely:

from smithy_aws_core.identity import ProcessCredentialsResolver

resolver = ProcessCredentialsResolver(command=["<insert command here>"])

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jonathan343]

I'm bringing this PR back to life now that we have a foundation for the default credentials chain and config resolution. I've adapted this to the pattern introduced in #749.

[jonathan343]

Note for reviewer: This is inspired by botocore's _windows_shell_split utility function.

[jonathan343]

Note for reviewer:

Most cases are ported from botocore: https://github.com/boto/botocore/blob/develop/tests/unit/test_compat.py#L111-L134

I also added two realistic Windows path cases

[arandito]

Thanks @jonathan343! This PR looks mostly good to me.

Just had a couple comments related to naming and error handling.

Let me know if you have any questions!

[arandito]

Some of the in-flight network providers introduce the concept of <ResolverName>ConfigurationError to make these errors surface more descriptively. Can we have a ProcessConfigurationError or something similar?

[arandito]

The naming convention for providers is currently <CanonicalName>Provider since they directly map to a standard slot in the chain.

Can we rename this to ProfileCredentialProcessProvider?

[arandito]

nit: json.loads can succeed for non-dict outputs like a list or string.

Can we add an isinstance(creds, dict) guard to raise a cleaner error? This would prevent a vague AttributeError: 'list' object has no attribute 'get' error from propagating up the chain.

[arandito]

nit: Should we also validate that the fields are strings before creating the identity object? Without it, the resolver sets non-string values that would raise at request-signing time.