credentials_cache method takes CredentialsCache, needs to take SharedCredentialsCache

[Mark-Simulacrum]

I think it's preferred to pass a credentials cache instead of a credentials provider. Right now, that's not really possible, because creating a credentials cache with credentials involves calling CredentialsCache::create_cache. This returns SharedCredentialsCache.

However, client builders take a CredentialsCache (not Shared) -- e.g., ec2, which means there doesn't seem to be a way to pass the cache-with-credentials in.

[jdisanti]

I don't think that create_cache is intended to be called by you during config. The expected configuration is to set both credentials_cache and credentials_provider if you want to customize caching. Something like:

let config = Config::builder()
    .credentials_cache(CredentialsCache::lazy_builder()
        // set some things ...
        .build()
    )
    .credentials_provider(my_provider)
    .build();

The Config builder will combine the two for you.

[Mark-Simulacrum]

I see. I think previously we were able to share a credential cache across multiple different clients, whereas with this design I think that isn't possible without some legwork to create a credential provider from a credentials cache?

[jdisanti]

Oh, sorry, I think I answered incorrectly the first time. I didn't realize the API was different between SdkConfig and Config here. Yeah, this is weird, and we should fix it.

If you can, use SdkConfig since that will easily share the credentials provider across clients.

[Mark-Simulacrum]

Hm, actually SdkConfig has the same problem it seems? https://docs.rs/aws-types/latest/aws_types/sdk_config/struct.Builder.html#method.credentials_cache takes a CredentialsCache.

Do you mean that we can create it via https://docs.rs/aws-config/latest/aws_config/fn.from_env.html which under the hood does the right thing?

[jdisanti]

That CredentialsCache that you pass into SdkConfig is really just a configuration that tells the builder how to create the cache rather than the cache itself. The actual cache is created inside of the SdkConfig's build method, and creating the service-specific configs from that SdkConfig should re-use it.

[Mark-Simulacrum]

That doesn't seem to be true looking at the code? SdkConfig::build doesn't do anything with the cache (src), and SdkConfig::set_credentials_cache doesn't either (src).

The service-specific config does that: https://docs.rs/aws-sdk-ec2/latest/src/aws_sdk_ec2/config.rs.html#786-798, but that's not super helpful for my case where I'm looking to share a set of cached credentials across multiple clients with distinct configurations, including across multiple services. I suppose this is enough that within one service I can make this work (by keeping around a built Config to go back from via to_builder)...

[rcoh]

You're correct—There is currently somewhere between a bug and an anti feature that although the provider is shared, each service ends up with its own cache. This isn't a huge issue for long-lived processes but it is quite annoying for things like a CLI where it's going to re-hit the provider for each service.

If these don't need to be long lived credentials, one hack workaround is to provide the credentials themselves by calling .provide_credentials().await? and passing that to the the config builder instead:

[Mark-Simulacrum]

OK, thanks for confirming. I'll look into the workaround, it might be feasible for us to use it for the current use case.

Can you say more about anti-feature though? What are the benefits to distinct caches per service for the credentials? Is there a design doc or similar on that?

[rcoh]

There aren't really (other than the somewhat esoteric use case of getting different caching strategies for different services)—it was an emergent/unexpected side-effect of a redesign that attempted to make it harder to misuse credentials providers, ironically. It's on our list to fix.

[rcoh]

this was resolved by the orchestrator however, #3427 does still exist and needs to be fixed.