feat: Add support for AWS Bedrock models

[supreme-gg-gg]

Closes #183

Example ModelConfig usage:

apiVersion: kagent.dev/v1alpha2
kind: ModelConfig
metadata:
  name: bedrock-claude
  namespace: kagent
spec:
// any valid model ID from aws bedrock will work
  model: anthropic.claude-3-sonnet-20240229-v1:0
  provider: Bedrock
  
  apiKeySecret: aws-bedrock-credentials
  
  bedrock:
    region: us-east-1

Requires setting credentials for aws in secret:

kubectl create secret generic aws-bedrock-credentials \
  --namespace kagent \
  --from-literal=AWS_ACCESS_KEY_ID=<access-key> \
  --from-literal=AWS_SECRET_ACCESS_KEY=<secret-key>

Alternatively, also supports Bedrock bearer token.
Adds golden test for the new bedrock translation.

---

Fixes the failing e2e test since yesterday due to new release of server-everything from MCP with breaking changes. Locks the version to prevent these issues in the future.

[Copilot]

Pull request overview

This pull request adds support for AWS Bedrock models as a new provider in the kagent system. Users can now configure AWS Bedrock models using the ModelConfig CRD with either IAM credentials (AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY) or bearer token authentication.

Changes:

• Added AWS Bedrock as a new model provider with region configuration support
• Implemented dual authentication methods: IAM credentials and bearer tokens
• Updated test fixtures to pin MCP server version and update tool names

Reviewed changes

Copilot reviewed 14 out of 15 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
python/uv.lock	Added boto3, botocore, jmespath, and s3transfer dependencies for AWS SDK support
python/packages/kagent-adk/pyproject.toml	Added boto3 dependency requirement
python/packages/kagent-adk/src/kagent/adk/types.py	Added Bedrock class and LiteLLM integration for Bedrock models
go/api/v1alpha2/modelconfig_types.go	Added BedrockConfig struct and ModelProviderBedrock enum value
go/api/v1alpha2/zz_generated.deepcopy.go	Auto-generated deep copy methods for BedrockConfig
go/config/crd/bases/kagent.dev_modelconfigs.yaml	Added Bedrock provider CRD schema with region field validation
helm/kagent-crds/templates/kagent.dev_modelconfigs.yaml	Mirror of CRD updates for Helm chart
go/internal/adk/types.go	Added Bedrock model type with JSON marshaling and parsing support
go/internal/controller/translator/agent/adk_api_translator.go	Implemented Bedrock model translation with IAM/bearer token auth logic
go/internal/httpserver/handlers/providers.go	Added Bedrock to supported providers list with required region parameter
go/internal/httpserver/handlers/models.go	Added sample Bedrock model IDs for Claude and Nova models
go/test/e2e/mocks/invoke_mcp_agent.json	Updated MCP tool name from "add" to "get-sum"
go/test/e2e/manifests/everything-mcp-server.yaml	Pinned MCP server to version 2026.1.14
go/test/e2e/manifests/add-numbers-agent.yaml	Updated tool name reference to "get-sum"
go/test/e2e/invoke_api_test.go	Updated test expectations for MCP tool name change

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[EItanya]

I mostly like this impl, but I don't think we should use the APIKeySecretKey here. That is really meant for the implementations which have a single secret value, but AWS often has multiple. Rather I think we should look at the available values in the secret. e.g. if AWS_BEARER_TOKEN_BEDROCK is available let's use that, otherwise use the access_token method. What do you think?

[supreme-gg-gg]

I mostly like this impl, but I don't think we should use the APIKeySecretKey here. That is really meant for the implementations which have a single secret value, but AWS often has multiple. Rather I think we should look at the available values in the secret. e.g. if AWS_BEARER_TOKEN_BEDROCK is available let's use that, otherwise use the access_token method. What do you think?

Yes this makes sense. I've made the change