feat!: change bedrock bearer token env variable to match AWS docs & boto3 convention

[ktdreyer]

Rename AWS_BEDROCK_API_KEY to AWS_BEARER_TOKEN_BEDROCK to align with the naming convention used in AWS Bedrock documentation and the AWS web console UI. This reduces confusion when developers compare LLS docs with AWS docs.

Closes #4147

[ktdreyer]

@skamenan7 what do you think?

[mattf]

please also update the provider data

[ktdreyer]

@mattf I think we should keep the Python str variable named aws_bedrock_api_key internally in Llama Stack, because 1) that matches the naming convention for other providers API keys, and 2) AWS does refer to this as an "API Key" in the UI and docs. I've amended the commit with this justification.

I've updated the BedrockProviderDataValidator description to make this clearer.

[mattf]

@mattf I think we should keep the Python str variable named aws_bedrock_api_key internally in Llama Stack, because 1) that matches the naming convention for other providers API keys, and 2) AWS does refer to this as an "API Key" in the UI and docs. I've amended the commit with this justification.

I've updated the BedrockProviderDataValidator description to make this clearer.

the way ProviderDataValidators are used is to parse user input provided via an x-llamastack-provider-data header.

so users will send requests like -

$ curl -L 'http://any-hosted-llama-stack.com/v1/chat/completions' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'x-llamastack-provider-data: {"aws_bedrock_api_key": "my-aws-bearer-token-for-bedrock' \
...

if aws is not consistent in its terminology, at least let us be consistent with the term we choose.

[ktdreyer]

Thanks for explaining that.

boto3 itself respects AWS_BEARER_TOKEN_BEDROCK, so that is a standard environment variable at this point (like the venerable AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY).

Eventually I could foresee a higher-level workflow that transforms AWS_ACCESS_KEY_ID+AWS_SECRET_ACCESS_KEY to AWS_BEARER_TOKEN_BEDROCK - (like https://pypi.org/project/aws-bedrock-token-generator/ does). We don't really want to force users to deploy long-lived keys anywhere.

I can support the decision to rename this all the way in LLS for clarity.

[skamenan7]

Hi @ktdreyer, LGTM, thanks. Yes having one field name will be helpful in my opinion too. Especially the name which we export/env variable to be the same in the code too.

[ktdreyer]

What should I do next to merge this?