Skip to content
Original file line number Diff line number Diff line change
Expand Up @@ -57,6 +57,10 @@ public List<RuntimeClientPlugin> getClientPlugins(GenerationContext context) {
.build())
// TODO: Initialize with the provider chain?
.nullable(true)
.initialize(writer -> {
writer.addImport("smithy_aws_core.credentials_resolvers", "CredentialsResolverChain");
writer.write("self.aws_credentials_identity_resolver = aws_credentials_identity_resolver or CredentialsResolverChain()");
})
.build())
.addConfigProperty(REGION)
.authScheme(new Sigv4AuthScheme())
Expand Down
Original file line number Diff line number Diff line change
@@ -1,6 +1,12 @@
# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: Apache-2.0

from .environment import EnvironmentCredentialsResolver
from .static import StaticCredentialsResolver
from .credentials_resolver_chain import CredentialsResolverChain

__all__ = ("EnvironmentCredentialsResolver", "StaticCredentialsResolver")
__all__ = (
"EnvironmentCredentialsResolver",
"StaticCredentialsResolver",
"CredentialsResolverChain",
)
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
from typing import Callable, List

from smithy_aws_core.credentials_resolvers import EnvironmentCredentialsResolver
from smithy_aws_core.identity import AWSCredentialsIdentity, AWSCredentialsResolver
from smithy_core.aio.interfaces.identity import IdentityResolver
from smithy_core.exceptions import SmithyIdentityException
from smithy_core.interfaces.identity import IdentityProperties

import os


def _env_creds_available() -> bool:
return bool(os.getenv("AWS_ACCESS_KEY_ID")) and bool(
os.getenv("AWS_SECRET_ACCESS_KEY")
)


def _build_env_creds() -> AWSCredentialsResolver:
return EnvironmentCredentialsResolver()


type CredentialSource = tuple[Callable[[], bool], Callable[[], AWSCredentialsResolver]]
_DEFAULT_SOURCES: list[CredentialSource] = [(_env_creds_available, _build_env_creds)]


class CredentialsResolverChain(
IdentityResolver[AWSCredentialsIdentity, IdentityProperties]
):
"""Resolves AWS Credentials from system environment variables."""

def __init__(self, *, sources: List[CredentialSource] | None = None):
if sources is None:
sources = _DEFAULT_SOURCES
self._sources: List[CredentialSource] = sources
self._credentials_resolver: AWSCredentialsResolver | None = None

async def get_identity(
self, *, identity_properties: IdentityProperties
) -> AWSCredentialsIdentity:
if self._credentials_resolver is not None:
return await self._credentials_resolver.get_identity(
identity_properties=identity_properties
)

for source in self._sources:
if source[0]():
self._credentials_resolver = source[1]()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are we actually calling here 😅 A state check and then a builder for the resolver?

I think this works, I'm wondering if we want to actually make a class for the abstraction rather than composing lists of functions. This is probably minor at this point, but may be worth spending some time on ergonomics later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - your right that this is a little confusing - I was hoping the typing itself would be sufficient... but its not.

This is separating "is available" from construction for a given credential source. We first call an "is available" callable to see if we should construct credentials from a given source - think cases like SSO or assume role or process credentials, ect where we can cheaply identify when the credentials are available (by checking the presence of env/config values), but actually constructing a resolver might be more expensive.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're concerned about perf for instantiation, you can always have a class method on the class reference. That can be used to check availability and then you have the class there to instantiate if we're ready. It's essentially the same abstraction just wrapped into a single input.

Copy link
Contributor Author

@alextwoods alextwoods Mar 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other consideration in this is that construction of a given resolver is based on the source - and its not always a 1:1 mapping and the order of precedence is important. As an example: assuming a role from a web identity. Assuming a role from a web identity token file can be specified either through the environment or through the shared config file and the order of precedence (limited just to static credentials and web identity) is:

  1. static credentials from ENV
  2. Web identity from ENV
  3. static credentials from profile
  4. web identity from profile.

In addition RE: construction, the resolver chain may need to construct certain resolvers with different options than we'd typically specify by default - an example of this is IMDS credentials. Since IMDS is the last option and is always checked, we usually use lower retries and timeouts to have it fail faster.

Edit: I do think a class/protocol interface makes a lot more sense. I'm working on an update to that, but I think the above answer still applies to why we might not just want to add an is_available method to AWS Credentials Resolvers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See commit for defining source as a class/Protocol - definitely easier to understand/use I think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Combining threads here - I'm not convinced that this Source concept is worth it. I see this as adding complexity unnecessarily. What I want to see is something dead simple, like:

class ChainedIdentityResolver[I](IdentityResolver[I]):

    def __init__(self, resolvers: Sequence[IdentityResolver[I]]) -> None:
        self._resolvers = resolvers

    async def get_identity(self, *, properties: _TypedProperties) -> I:
        for resolver in self._resolvers:
            try:
                return await resolver.get_identity(properties=properties)
            except SmithyIdentityException as e:
                logger.debug(
                    "Failed to resolve identity from %s: %s", type(resolver), e
                )

        raise SmithyIdentityException("Failed to resolve identity from resolver chain.")

I'm currently working on changing the interfaces here, so maybe we should just punt on this for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the resolvers we currently have (env and IMDS) that approach is fine. I think theres three reasons it doesn't work as simply as that for the full aws credentials resolver chain

  1. Availability and resolution are separate concerns - as an example - if a credential_process is configured, the process resolver should be considered "available" and should be used by the chain even if executing that processes fails/doesn't return credentials. (ie, we wouldn't move on to the next resolver if a configured credential process fails).
  2. Sources don't map 1:1 to resolvers - resolvers like Assume role or web identity can be configured multiple different ways at different levels of precedence - ie, they are different sources.
  3. Separation of concerns - configuration sources vs resolver properties. How and where we source configuration generally shouldn't be a concern for an individual resolver - that is, I'd argue that something like a web identity resolver shouldn't need to be concerned with where/how the token file is specified (env, shared config, ect) - it should just know how to use that.

Again though - I think these are longer term concerns, a simple sequence of resolvers is sufficient for what is available now so I'm happy to drop this PR and leave it to future design work to describe how this should work.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. That's news to me. Why not? And there's ways around that which aren't as complicated, such as having different exception types.
  2. If they don't, they need to be refactored until they do. If you have a resolver that checks three different areas that can't be run sequentially then it's dangerous to run at any point.
  3. I don't agree. The purpose of a credential resolver is to source credentials from some method of configuration. Constructor arguments can be used to narrow their search if necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With something like a configured credential_process- it was explicitly configured and I'd argue that it should be treated as authoritative if present. However, looking at existing SDK behavior, this seems to be underspecified and likely inconsistent across SDKs - both the Ruby and Java SDKs will resolve process credentials and fail during a request, surfacing the command failure in that case, but I'm guessing there are other SDKs that might move on in the chain....

We could potentially use different exception types to signal whether credentials are applicable/configured vs invalid, but generally I'd prefer not to use exceptions for control flow.

On separation of concerns, I see resolvers as consumers of configuration rather than being responsible for doing the resolution of configuration - I think making an identity resolver responsible both for resolving configuration and for then resolving an identity from it increases the complexity and mixes two separate concerns.

That said again, all of those are longer term concerns I think and with the ENV/IMDS resolvers only, sources are unnecessary and I'm happy to drop this PR for a simple sequence of resolvers.

return await self._credentials_resolver.get_identity(
identity_properties=identity_properties
)

raise SmithyIdentityException(
"None of the configured credentials sources were able to resolve credentials."
)
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
import pytest

from smithy_aws_core.credentials_resolvers import (
CredentialsResolverChain,
StaticCredentialsResolver,
)
from smithy_aws_core.identity import AWSCredentialsIdentity
from smithy_core.exceptions import SmithyIdentityException
from smithy_core.interfaces.identity import IdentityProperties


async def test_no_sources_resolve():
resolver_chain = CredentialsResolverChain(sources=[])
with pytest.raises(SmithyIdentityException):
await resolver_chain.get_identity(identity_properties=IdentityProperties())


async def test_env_credentials_resolver_not_set(monkeypatch: pytest.MonkeyPatch):
monkeypatch.delenv("AWS_ACCESS_KEY_ID", raising=False)
monkeypatch.delenv("AWS_SECRET_ACCESS_KEY", raising=False)
resolver_chain = CredentialsResolverChain()

with pytest.raises(SmithyIdentityException):
await resolver_chain.get_identity(identity_properties=IdentityProperties())


async def test_env_credentials_resolver_partial(monkeypatch: pytest.MonkeyPatch):
monkeypatch.setenv("AWS_ACCESS_KEY_ID", "akid")
monkeypatch.delenv("AWS_SECRET_ACCESS_KEY", raising=False)
resolver_chain = CredentialsResolverChain()

with pytest.raises(SmithyIdentityException):
await resolver_chain.get_identity(identity_properties=IdentityProperties())


async def test_env_credentials_resolver_success(monkeypatch: pytest.MonkeyPatch):
monkeypatch.setenv("AWS_ACCESS_KEY_ID", "akid")
monkeypatch.setenv("AWS_SECRET_ACCESS_KEY", "secret")
resolver_chain = CredentialsResolverChain()

credentials = await resolver_chain.get_identity(
identity_properties=IdentityProperties()
)
assert credentials.access_key_id == "akid"
assert credentials.secret_access_key == "secret"


async def test_custom_sources_with_static_credentials():
static_credentials = AWSCredentialsIdentity(
access_key_id="static_akid",
secret_access_key="static_secret",
)
static_resolver = StaticCredentialsResolver(credentials=static_credentials)
resolver_chain = CredentialsResolverChain(
sources=[(lambda: False, lambda: None), (lambda: True, lambda: static_resolver)] # type: ignore
)

credentials = await resolver_chain.get_identity(
identity_properties=IdentityProperties()
)
assert credentials.access_key_id == "static_akid"
assert credentials.secret_access_key == "static_secret"