Enhancement: Simplify logic around BEDROCK_AWS_ACCESS_KEY_ID and BEDROCK_AWS_SECRET_ACCESS_KEY

[shinglyu]

What features would you like to see added?

Replace BEDROCK_AWS_ACCESS_KEY_ID and BEDROCK_AWS_SECRET_ACCESS_KEY with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, and rely on AWS SDK to simply the logic.

More details

If BEDROCK_AWS_ACCESS_KEY_ID and BEDROCK_AWS_SECRET_ACCESS_KEY is not provided, the AWS SDK will use its default credential resolution logic. In that logic, it will look for AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables. So directly passing the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY will be sufficient, and we can remove the custom logic around checking BEDROCK_-prefixed variants.

Also, for users using AWS STS CLI to assume roles, the user needs to pass the AWS_SESSION_TOKEN as well. In that case, customer need to pass this in .env:

AWS_ACCESS_KEY_ID=your_access_key_here
AWS_SECRET_ACCESS_KEY=your_secret_key_here
AWS_SESSION_TOKEN=your_session_token_here

In this case, there is no BEDROCK_AWS_SESSION_TOKEN, and the BEDROCK_ ones make things complicated.

Which components are impacted by your request?

Endpoints

Pictures

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[khfung]

I think it is good to have two different environment valuables because one is for the bedrock and another one is for rag
Just my view only

[shinglyu]

@khfung Oh I wasn't aware of the RAG support. In that case maybe adding BEDROCK_AWS_SESSION_TOKEN is a better idea?

[ldavis9000aws]

Even so, we still need STS support for temporary credentials.