[shohamazon]

What

Adds an optional credentials parameter to generate_iam_auth_token, ElastiCacheIAMAuthTokenProvider, and ElastiCacheIAMAuthTokenManager, so a caller can sign with a botocore credentials object it already holds instead of supplying a session.

generate_iam_auth_token(
    serverless_cache_name="my-cache",
    user_id="default.iam-user",
    region="us-east-1",
    credentials=credentials,   # instead of session=...
)

credentials takes precedence when both are given. Existing callers are unaffected.

Why

A client that integrates with an application's existing boto3 client has the credentials behind that client but not the session it was created from — a boto3 client keeps no reference back to one. Today the only way to sign a cache token with the application's own identity is to ask it for the session as well, which is an extra argument that exists purely to reach get_credentials().

The session was already used for just two things: get_credentials() and, as a last fallback, get_config_variable("region"). A caller that passes a region explicitly only needs the first.

Rotation is preserved

_resolve_credentials still re-reads per token request and calls get_frozen_credentials(), so a refreshable credentials object refreshes itself exactly as the session's would: the refresh callable is captured inside the object when the chain resolves it, so it needs nothing from the session afterwards. The new tests cover a RefreshableCredentials object vending rotated keys across two get_token() calls.

[mwaisaida-13]

Thanks, this is a clean addition! A few things before merge:

• CHANGELOG, please add the new parameter under Unreleased / Added.

• README. The Credentials section only describes the default chain. Could you add a short "bring your own credentials" paragraph with the snippet from the PR description?