feat(bedrock): add profile field for AWS named profile / SSO auth

[AndreKurait]

Summary

Adds a per-key profile field on bedrock_key_config that selects a named profile from ~/.aws/config / ~/.aws/credentials (including AWS SSO profiles via the SDK's built-in ssocreds provider). Used when access_key/secret_key are empty; threads through aws-sdk-go-v2's default credential chain via config.WithSharedConfigProfile. Composes with role_arn — the profile's resolved credentials become the source identity for STS AssumeRole.

This unblocks per-key multi-AWS-account load balancing for users on corporate SSO without requiring static keys or process-wide AWS_PROFILE env vars.

Closes #4029

Changes

• Schema — new Profile *EnvVar field on BedrockKeyConfig (core/schemas/account.go).
• Signing paths (3) — added profile parameter and WithSharedConfigProfile branch to:
  • signAWSRequest in core/providers/bedrock/bedrock.go (net/http path; 14 call sites updated)
  • signAWSRequestFastHTTP in core/providers/bedrock/signer.go (fasthttp path)
  • uploadToS3 in core/providers/bedrock/s3.go (batch path; caller in bedrock.go updated)
• AssumeRole cache — profile name included in assumeRoleCredsCache key (profile:<name> source identity) so two profiles assuming the same role do not collide.
• Persistence — BedrockProfile GORM column on TableKey, copy in BeforeSave/AfterFind, encryption pair, included in BedrockKeyConfig reconstruction (framework/configstore/tables/key.go); new migrationAddBedrockProfileColumn (framework/configstore/migrations.go); copy in rdb.go (4 sites); cleared in virtualkey.go redaction.
• Validation / API surface — new profile property in transports/config.schema.json and docs/openapi/schemas/management/providers.yaml (also adds the previously-missing role_arn/external_id/session_name entries for the OpenAPI schema, mirroring [Bug]: Published JSON schema missing role_arn, session_name, external_id in bedrock_key_config #2484's class of fix).
• Redaction — added to clientconfig.go and transports/bifrost-http/lib/config.go.
• UI — new "AWS Profile (Optional)" input on the Bedrock key form, shown in the IAM Role / Explicit Credentials tabs (cleared when switching to API Key tab); type and Zod schema updates.
• Docs — new "AWS Profile / SSO" section in docs/providers/supported-providers/bedrock.mdx (renumbers AssumeRole to section 4) with config examples, multi-account load-balance example, SSO token expiry note, Docker volume-mount guidance, and region-precedence note. New row in the bedrock_key_config field table.
• Test — extended TestBeforeSave_DoesNotMutateSharedProviderConfigs in framework/configstore/encryption_test.go to exercise the round-trip (no-mutation + DB persistence) of the new Profile field.

Mirrors the plumbing pattern from #1882 (which added role_arn/external_id/session_name).

Type of change

• Feature
• Documentation

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• UI (React)
• Docs

How to test

# Core
cd core && go build ./providers/bedrock/... ./schemas/...
go test ./providers/bedrock/... -count=1 -short
# → ok  github.com/maximhq/bifrost/core/providers/bedrock  0.810s

# Framework round-trip persistence test
cd ../framework && go test ./configstore/... -run TestBeforeSave_DoesNotMutateSharedProviderConfigs -count=1
# → ok  github.com/maximhq/bifrost/framework/configstore  1.320s

# Vet
go vet ./configstore/... && (cd ../core && go vet ./providers/bedrock/... ./schemas/...)
# → clean

End-to-end smoke test (multi-account):

1. Configure two AWS profiles in ~/.aws/config (e.g. corporate SSO):

   [profile acct-a]
   sso_session = my-sso
   sso_account_id = 111111111111
   sso_role_name = BedrockInvoke
   region = us-east-1
   
   [profile acct-b]
   sso_session = my-sso
   sso_account_id = 222222222222
   sso_role_name = BedrockInvoke
   region = us-west-2
   
   [sso-session my-sso]
   sso_start_url = https://my-corp.awsapps.com/start
   sso_region = us-east-1
   

2. aws sso login --sso-session my-sso
3. Run Bifrost with config.json containing two Bedrock keys (one per profile, same model in models[]).
4. curl http://localhost:8080/anthropic/v1/messages -d '{"model":"bedrock/anthropic.claude-3-5-sonnet-20241022-v2:0", ...}' — observe weighted-random selection between accounts.
5. Pin to a single account via -H "x-bf-api-key: <key-name>" for deterministic routing.

I do not have a corporate SSO setup to validate the SSO leg end-to-end; static-key + AssumeRole paths are unchanged and covered by existing tests.

Breaking changes

• Yes
• No

The new profile field is optional; existing bedrock_key_config blobs deserialize unchanged. The new bedrock_profile GORM column is added by migrationAddBedrockProfileColumn. signAWSRequest/signAWSRequestFastHTTP/uploadToS3 are package-private, so the new positional arg is contained.

Related issues

Closes #4029
Related: #1882 (added STS AssumeRole fields), #268 (added default credential chain fallback)

Security considerations

• Profile is treated as a secret-like field for consistency with other Bedrock credential fields: encrypted at rest in TableKey via encryptEnvVarPtr, redacted in clientconfig.go and lib/config.go. Profile names themselves aren't secret, but treating them uniformly avoids accidental leaks (e.g. if a profile name encodes account/team identifiers).
• WithSharedConfigProfile reads from the user's filesystem (~/.aws/config, ~/.aws/credentials, ~/.aws/sso/cache). When running under Docker, operators must explicitly mount these — documented in the new bedrock.mdx section.
• AssumeRole cache key now includes profile:<name> so cross-profile/role collisions are impossible.
• SSO bearer-token storage (~/.aws/sso/cache) and lifetime are managed entirely by aws-sdk-go-v2's ssocreds provider; this PR does not introduce custom token handling.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go) — go build clean across core, framework, and transports (with local replace directives that I reverted before commit). UI not built locally; existing CI covers it.
• I verified the round-trip persistence test passes on the new field

Summary by CodeRabbit

• New Features

  • Added AWS named profile (including SSO) support to Bedrock provider authentication. Users can now specify a profile from ~/.aws/config instead of explicit access keys.

• Documentation

  • Updated Bedrock provider documentation with AWS Profile/SSO configuration guidance, profile precedence rules, and Docker mounting requirements.

• UI Updates

  • Added "AWS Profile" input field in Bedrock authentication form when using IAM Role authentication.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds an optional per-key AWS profile to Bedrock provider, resolves credentials via that profile when present (including SSO), threads the profile through signing and S3 uploads, persists it in the DB with migration and encryption support, and updates UI, schemas, docs, and tests.

Changes

Bedrock AWS Profile & SSO Feature

Layer / File(s)	Summary
Data model and schema contracts core/schemas/account.go, docs/openapi/schemas/management/providers.yaml, transports/config.schema.json, ui/lib/schemas/providerForm.ts, ui/lib/types/schemas.ts	Adds Profile *EnvVar to BedrockKeyConfig and extends OpenAPI/JSON/Zod/TS schemas and provider form schema.
Profile-aware credential resolution & signer core/providers/bedrock/bedrock.go, core/providers/bedrock/signer.go	signAWSRequest/signing wrappers now accept a profile EnvVar and resolve AWS config with config.WithSharedConfigProfile(profile) when appropriate; Authorization/session token use resolved credentials; AssumeRole cache sourceIdentity includes profile: prefix for profile-based sources.
S3 upload helper refactor core/providers/bedrock/s3.go	uploadToS3 now accepts *schemas.BedrockKeyConfig, delegates credential resolution to resolveAWSConfig, and extracts s3PutObject helper to perform PutObject using resolved aws.Config.
Propagate profile through signing call sites core/providers/bedrock/bedrock.go	All Bedrock signing call sites (runtime, agent, EventStream, model listing, S3 file operations, batch submission/list/retrieve/cancel/manifest) pass BedrockKeyConfig.Profile into signing.
Batch inline upload alignment core/providers/bedrock/bedrock.go	BatchCreate inline S3 upload now uses full BedrockKeyConfig for upload credential resolution, aligning upload identity with job submission.
Database persistence & migrations framework/configstore/migrations.go, framework/configstore/rdb.go, framework/configstore/tables/key.go	Adds bedrock_profile column and migration; persists BedrockKeyConfig.Profile to TableKey.BedrockProfile; maps/encrypts/decrypts in GORM hooks and updates key upsert/create flows.
UI form and validation ui/app/workspace/providers/fragments/apiKeysFormFragment.tsx, ui/lib/schemas/providerForm.ts	Adds optional “AWS Profile” EnvVar input, clears it when switching auth type, and validates that profile cannot be supplied alongside explicit access/secret keys.
Redaction, tests, docs framework/configstore/clientconfig.go, transports/bifrost-http/lib/config.go, framework/configstore/encryption_test.go, docs/providers/supported-providers/bedrock.mdx	Redacts Profile in provider listings, extends encryption round-trip test for Profile persistence/non-mutation, and documents AWS Profile / SSO behavior and operational notes.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

• maximhq/bifrost#3531: Touches Bedrock SigV4 signing flow; related refactor work on signAWSRequest plumbing.

Suggested reviewers

• danpiths
• roroghost17
• akshaydeo

Poem

🐰 I hopped through configs, fields, and keys,

added profiles to calm credential seas.
SSO and profiles now play nice and clear,
Bedrock sings across accounts far and near.
🥕✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	Title clearly and concisely summarizes the main feature: adding a profile field for AWS named profile/SSO authentication to Bedrock provider configuration.
Description check	✅ Passed	Description is comprehensive, following the template structure with Summary, Changes, Type of change, Affected areas, How to test, Breaking changes, Related issues, Security considerations, and Checklist all completed.
Linked Issues check	✅ Passed	All coding requirements from issue #4029 are addressed: optional profile field on BedrockKeyConfig, profile threading via WithSharedConfigProfile, AssumeRole cache key updates, persistence layer, API surface, UI form, documentation, and tests.
Out of Scope Changes check	✅ Passed	All changes directly support the #4029 objective of adding per-key AWS profile/SSO support. No unrelated modifications detected; even the OpenAPI schema additions for role_arn/external_id/session_name mirror prior #2484-style fixes and are scoped to Bedrock credential configuration.
Docstring Coverage	✅ Passed	Docstring coverage is 92.86% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.12.2)

level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies"

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
6 out of 10 committers have signed the CLA.

✅ impoiler
✅ akshaydeo
✅ AndreKurait
✅ alexef
✅ axelray-dev
✅ BearTS
❌ TejasGhatte
❌ roroghost17
❌ stepsecurity-app[bot]
❌ Pratham-Mishra04
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

ui/lib/schemas/providerForm.ts (1)

111-142: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Disallow profile when static Bedrock keys are provided.

profile is accepted even when both access_key and secret_key are set, which permits ambiguous auth config that conflicts with the Bedrock profile semantics in this PR.

Suggested fix

 const BedrockKeyConfigSchema = z
 	.object({
 		access_key: z.string(),
 		secret_key: z.string(),
 		session_token: z.string().optional(),
 		region: z.string().min(1, "Region is required for Bedrock keys"),
-		profile: z.string().optional(),
+		profile: z.string().trim().optional(),
 		role_arn: z.string().optional(),
 		external_id: z.string().optional(),
 		session_name: z.string().optional(),
 		arn: z.string().optional(),
 		batch_s3_config: BatchS3ConfigSchema.optional(),
 	})
 	.refine(
 		(data) => {
 			const accessKey = data.access_key?.trim() || "";
 			const secretKey = data.secret_key?.trim() || "";
 			const bothEmpty = accessKey === "" && secretKey === "";
 			const bothProvided = accessKey !== "" && secretKey !== "";
+			const profile = data.profile?.trim() || "";
 
 			// Either both empty (IAM role auth) or both provided (explicit credentials)
 			if (!bothEmpty && !bothProvided) {
 				return false;
 			}
+
+			// Profile-based auth is only valid when static keys are not provided.
+			if (bothProvided && profile !== "") {
+				return false;
+			}
 
 			// Check for session token when using IAM role path (both keys empty)
 			const sessionToken = data.session_token?.trim() || "";
 			if (bothEmpty && sessionToken !== "") {
 				return false;
 			}
 
 			return true;
 		},
 		{
-			message: "For Bedrock: either provide both Access Key and Secret Key, or leave both empty for IAM role authentication",
-			path: ["access_key"],
+			message:
+				"For Bedrock: either provide both Access Key and Secret Key, or leave both empty for IAM role/profile authentication; profile cannot be combined with static keys",
+			path: ["profile"],
 		},
 	);

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@ui/lib/schemas/providerForm.ts` around lines 111 - 142, The refine predicate
on the schema (the function that validates access_key, secret_key, and
session_token) must also reject a non-empty profile when static credentials are
provided: if access_key and secret_key are both provided (access_key !== "" &&
secret_key !== "") then ensure data.profile is empty/undefined and return false
if it isn’t; update the validation error to indicate “profile must be omitted
when using explicit Access Key and Secret Key” (adjust the message/path from
access_key to profile or add a second error) so the check in the refine with
symbols access_key, secret_key, session_token, and profile enforces that profile
cannot be set alongside static Bedrock keys.

core/providers/bedrock/bedrock.go (1)

2901-2915: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Thread AssumeRole settings into uploadToS3.

This upload path only forwards access key / secret / session token / profile, so it cannot honor BedrockKeyConfig.RoleARN, ExternalID, or RoleSessionName. Every other S3/Bedrock request in this file signs via signAWSRequest(...), which does assume the configured role. A key that relies on profile + role_arn will therefore upload the JSONL file with the source credentials and then create the batch job with assumed-role credentials, which commonly fails with S3 authorization errors on the input object. Please extend uploadToS3 to take the role fields as well, or route this upload through the same role-aware signing helper used by the rest of the provider.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@core/providers/bedrock/bedrock.go` around lines 2901 - 2915, The uploadToS3
call currently only forwards AccessKey/SecretKey/SessionToken/Profile and
therefore ignores BedrockKeyConfig.RoleARN, ExternalID, and RoleSessionName,
causing uploads to use source creds instead of the assumed role; update the
upload path to either accept the role-related fields (RoleARN, ExternalID,
RoleSessionName) on uploadToS3 and have uploadToS3 perform STS AssumeRole to
produce temporary creds before uploading, or reuse the existing signAWSRequest
helper to sign the S3 PUT with assumed-role credentials the same way other
functions do (ensure you reference uploadToS3,
BedrockKeyConfig.RoleARN/ExternalID/RoleSessionName, and signAWSRequest so the
code routes S3 uploads through role-aware signing).

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@core/providers/bedrock/signer.go`:
- Around line 274-295: signAWSRequestFastHTTP currently loads credentials via
config.LoadDefaultConfig but ignores RoleARN/ExternalID/RoleSessionName so it
skips AssumeRole behavior that signAWSRequest (in
core/providers/bedrock/bedrock.go) supports; extract the credential resolution
logic into a shared role-aware helper (e.g. resolveAWSCredentialsWithRole or
getAWSCredentials) that accepts ctx, region, profile, optional RoleARN,
ExternalID, RoleSessionName and returns the resolved
accessKey/secretKey/sessionToken or an error, implement AssumeRole using STS
when RoleARN is provided, and update both signAWSRequestFastHTTP and
signAWSRequest to call that helper instead of directly calling
config.LoadDefaultConfig so both fasthttp and net/http signers honor role-based
profiles consistently.

---

Outside diff comments:
In `@core/providers/bedrock/bedrock.go`:
- Around line 2901-2915: The uploadToS3 call currently only forwards
AccessKey/SecretKey/SessionToken/Profile and therefore ignores
BedrockKeyConfig.RoleARN, ExternalID, and RoleSessionName, causing uploads to
use source creds instead of the assumed role; update the upload path to either
accept the role-related fields (RoleARN, ExternalID, RoleSessionName) on
uploadToS3 and have uploadToS3 perform STS AssumeRole to produce temporary creds
before uploading, or reuse the existing signAWSRequest helper to sign the S3 PUT
with assumed-role credentials the same way other functions do (ensure you
reference uploadToS3, BedrockKeyConfig.RoleARN/ExternalID/RoleSessionName, and
signAWSRequest so the code routes S3 uploads through role-aware signing).

In `@ui/lib/schemas/providerForm.ts`:
- Around line 111-142: The refine predicate on the schema (the function that
validates access_key, secret_key, and session_token) must also reject a
non-empty profile when static credentials are provided: if access_key and
secret_key are both provided (access_key !== "" && secret_key !== "") then
ensure data.profile is empty/undefined and return false if it isn’t; update the
validation error to indicate “profile must be omitted when using explicit Access
Key and Secret Key” (adjust the message/path from access_key to profile or add a
second error) so the check in the refine with symbols access_key, secret_key,
session_token, and profile enforces that profile cannot be set alongside static
Bedrock keys.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 8cf94831-6095-4dc6-bba2-9e941d350a95

📥 Commits

Reviewing files that changed from the base of the PR and between 2c0e7cf and 8397278.

📒 Files selected for processing (17)

• core/providers/bedrock/bedrock.go
• core/providers/bedrock/s3.go
• core/providers/bedrock/signer.go
• core/schemas/account.go
• docs/openapi/schemas/management/providers.yaml
• docs/providers/supported-providers/bedrock.mdx
• framework/configstore/clientconfig.go
• framework/configstore/encryption_test.go
• framework/configstore/migrations.go
• framework/configstore/rdb.go
• framework/configstore/tables/key.go
• framework/configstore/tables/virtualkey.go
• transports/bifrost-http/lib/config.go
• transports/config.schema.json
• ui/app/workspace/providers/fragments/apiKeysFormFragment.tsx
• ui/lib/schemas/providerForm.ts
• ui/lib/types/schemas.ts

[greptile-apps]

Confidence Score: 5/5

Safe to merge; all plumbing is additive and follows established patterns, the new field is optional, and no existing paths are altered.

Every changed layer — credential resolution, signing, S3 upload, GORM persistence, encryption, redaction, UI, config schema — follows the exact same pattern used when role_arn/external_id/session_name were added. The resolveAWSConfig refactor centralises logic rather than duplicating it, and EnvVar.Redacted() is nil-safe so the new redaction call is safe for unset fields. The AssumeRole cache correctly distinguishes profile-sourced identities from the default chain. No existing code paths are modified in a breaking way.

No files require special attention. signer.go's signAWSRequestFastHTTP remains unused but that is a pre-existing condition noted in a previous review thread.

Important Files Changed

Filename	Overview
core/providers/bedrock/bedrock.go	Refactored credential resolution into resolveAWSConfig helper; threads profile parameter through all 14 signAWSRequest call sites and BatchCreate; cache key uses "profile:<name>" source identity so two profiles assuming the same role cannot collide
core/providers/bedrock/s3.go	Replaced raw access/secret key strings with *BedrockKeyConfig so uploadToS3 now goes through resolveAWSConfig, picking up profile, SSO, and AssumeRole consistently with the request-signing path
core/providers/bedrock/signer.go	Updated signAWSRequestFastHTTP signature to accept schemas.EnvVar types and delegate to resolveAWSConfig; function is still unused in production but the parameter update is correct
core/schemas/account.go	Added Profile *EnvVar field to BedrockKeyConfig with correct json:"profile,omitempty" tag and clear documentation
framework/configstore/migrations.go	Added migrationAddBedrockProfileColumn that conditionally adds a nullable TEXT column; has a proper rollback; adding a nullable column with no default is a fast metadata operation on both SQLite and PostgreSQL ≥11
framework/configstore/tables/key.go	Added BedrockProfile *schemas.EnvVar column, BeforeSave copy + encrypt, AfterFind decrypt + reconstruct, and AfterFind condition — all mirror the existing BedrockRoleARN pattern correctly
framework/configstore/rdb.go	Added BedrockProfile assignment in all four write paths
framework/configstore/tables/virtualkey.go	Added BedrockProfile = nil redaction in virtual-key AfterFind; mirrors the pattern for other Bedrock credential fields
transports/bifrost-http/lib/config.go	Added cfg.Profile = cfg.Profile.Redacted() in GetAllKeys; EnvVar.Redacted() is nil-safe, so this is correct regardless of whether the field is set
framework/configstore/clientconfig.go	Added nil-guarded Profile redaction in Redacted(); consistent with existing guard pattern for other pointer fields
transports/config.schema.json	Added profile string property to bedrock_key_config; type and placement match the existing session_name pattern
ui/app/workspace/providers/fragments/apiKeysFormFragment.tsx	Profile field is shown only in iam_role tab, cleared on switch to explicit and api_key tabs; correct data-testid included
ui/lib/schemas/providerForm.ts	Added Zod .refine that rejects the combination of profile + explicit access/secret keys; correct validation path and message
ui/lib/types/schemas.ts	Added optional profile to bedrockKeyConfigSchema and a matching .refine guard; mirrors providerForm.ts validation logic
framework/configstore/encryption_test.go	Extended TestBeforeSave_DoesNotMutateSharedProviderConfigs to cover Profile no-mutation and DB round-trip

_{Reviews (2): Last reviewed commit: "feat(bedrock): add `profile` field for A..." | Re-trigger Greptile}

[AndreKurait]

Thanks @coderabbitai and @greptile-apps for the careful review. Pushed ce97aab8e (rebased on latest dev) addressing all four findings. PR description's checklist still holds: build clean across core/framework, go vet clean, the round-trip persistence test still passes.

What changed in this revision

1. Shared role-aware credential resolver (CodeRabbit's main concern about signAWSRequestFastHTTP and uploadToS3 dropping role_arn)

Extracted resolveAWSConfig in core/providers/bedrock/bedrock.go. It performs the full credential chain — static keys → default chain (with optional WithSharedConfigProfile) → STS AssumeRole wrapping — and returns an aws.Config whose Credentials are already in the right state. The three signing/upload paths now route through it:

• signAWSRequest (HTTP / net/http) — unchanged behavior, just uses the helper.
• signAWSRequestFastHTTP (fasthttp) — was previously a string-based, role-blind helper. Reworked to take the full *schemas.EnvVar set (accessKey, secretKey, sessionToken, profile, roleARN, externalID, sessionNameEnv) and call the same helper. AssumeRole now applies on this path too. (Function still has no in-tree callers; the change makes it safe to wire up later without silently downgrading auth.)
• uploadToS3 — signature changed from raw string creds to cfg *schemas.BedrockKeyConfig. The batch S3 upload now signs as the assumed role when role_arn is set on the key, matching the credentials that subsequently submit the batch job. Caller in bedrock.go updated.

The two paths can no longer drift on AssumeRole / profile semantics — they share one resolver.

2. UI: profile gated to IAM Role tab + Zod refines

• ui/app/workspace/providers/fragments/apiKeysFormFragment.tsx: AWS Profile input now only renders when bedrockAuthType === "iam_role". Switching to "Explicit Credentials" or "API Key" clears it (previously only the API Key tab cleared it).
• ui/lib/types/schemas.ts and ui/lib/schemas/providerForm.ts: added a refine that rejects profile when both access_key and secret_key are set — error reads "Profile cannot be combined with explicit Access Key / Secret Key" and is anchored to the profile field.

3. Docs: redundant SSO cache mount removed

docs/providers/supported-providers/bedrock.mdx now mounts only ~/.aws:/root/.aws:ro and notes that the SSO cache lives under that parent.

Why I did not extract a "real" caller for signAWSRequestFastHTTP

Greptile pointed out it's still dead code. I deliberately kept it — wiring it into a Mantle path would be a separate change with broader behavior implications, and CodeRabbit's actionable concern (silent role-skipping if it ever IS called) is fully addressed by the shared-resolver refactor. Happy to remove the function entirely in a follow-up if maintainers prefer that over keeping it ready.

Verification

cd core && go build ./providers/bedrock/... ./schemas/...                                  # clean
go test ./providers/bedrock/... -count=1 -short                                            # ok 0.708s
go vet ./providers/bedrock/... ./schemas/...                                               # clean

cd ../framework && go test ./configstore/... -run TestBeforeSave_DoesNotMutateSharedProviderConfigs -count=1
# ok github.com/maximhq/bifrost/framework/configstore  1.147s

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@AndreKurait — Thank you for the detailed write-up and for addressing all four findings so thoroughly. Here's a summary of what each fix closes out:

Previous concern	Resolution in ce97aab8e	Status
signAWSRequestFastHTTP silently drops role_arn	Now routes through shared resolveAWSConfig; full static→default→AssumeRole chain applied	✅
uploadToS3 signs with bare creds, ignoring role_arn	Signature changed to cfg *schemas.BedrockKeyConfig; same resolver applied	✅
UI: profile field visible on wrong auth tabs	Gated to bedrockAuthType === "iam_role" only; Zod refine rejects profile+explicit-key combo	✅
Docs: redundant SSO cache bind-mount	Collapsed to ~/.aws:/root/.aws:ro with a note that SSO cache lives under that parent	✅

The resolveAWSConfig extraction is a clean fix — having one place that owns the credential chain means the three paths can't silently diverge on AssumeRole/profile semantics going forward.

The rationale for keeping signAWSRequestFastHTTP as an unconnected but now-safe helper is sound; the risk was that a future caller would silently downgrade auth, and that's fully closed by the shared resolver.

Looks good to me — changes are well-reasoned, verified, and documented.

(∩｀-´)⊃━☆ﾟ.*･｡ﾟ

---

🧠 Learnings used

Learnt from: CR
Repo: maximhq/bifrost PR: 0
File: .greptile/rules.md:0-0
Timestamp: 2026-06-03T21:47:30.819Z
Learning: Applies to core/providers/interface.go : Provider interface changes are high-blast-radius: check all providers, request type constants, allowed-request gates, handlers, integrations, config schema, UI constants, docs, and tests.

[greptile-apps]

Both fixes look correct and complete.

On the UI concern (my comment): The profile field is now properly gated — it only renders under {bedrockAuthType === "iam_role" && (...)}, and switching to the Explicit Credentials tab explicitly calls form.setValue("key.bedrock_key_config.profile", undefined). The Zod refine that rejects profile when both access_key/secret_key are set adds a nice belt-and-suspenders defense at the schema level too.

On CodeRabbit's signAWSRequestFastHTTP concern: signer.go now delegates directly to resolveAWSConfig(...) with the full credential parameter set, so both the fasthttp and net/http signing paths share one resolver and can no longer drift on AssumeRole / profile semantics. The shared helper approach is the right call here.

The rationale for keeping signAWSRequestFastHTTP without an in-tree caller is reasonable — silently downgrading auth would have been a real hazard, and the corrected signature is a safe foundation for a future Mantle wiring without a separate PR.

LGTM on this revision.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[coderabbitai]

Actionable comments posted: 2

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

core/providers/bedrock/bedrock.go (1)

2930-2943: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use the effective batch role for the inline S3 upload.

Line 2938 passes key.BedrockKeyConfig directly into uploadToS3, but BatchCreate may override the role with request.ExtraParams["role_arn"] and then submits the job with that effective role on Line 2960. When those differ, the JSONL upload is signed with one identity and the batch job runs as another, which can break cross-account buckets with AccessDenied or leave the input object under the wrong principal.

Suggested fix

-		if bifrostErr := uploadToS3(
-			ctx,
-			key.BedrockKeyConfig,
+		uploadCfg := key.BedrockKeyConfig
+		if roleArn != "" && (uploadCfg == nil || uploadCfg.RoleARN == nil || uploadCfg.RoleARN.GetValue() != roleArn) {
+			copied := schemas.BedrockKeyConfig{}
+			if uploadCfg != nil {
+				copied = *uploadCfg
+			}
+			copied.RoleARN = schemas.Ptr(schemas.EnvVar{Val: roleArn})
+			uploadCfg = &copied
+		}
+		if bifrostErr := uploadToS3(
+			ctx,
+			uploadCfg,
 			region,
 			bucket,
 			s3Key,
 			jsonlData,
 		); bifrostErr != nil {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@core/providers/bedrock/bedrock.go` around lines 2930 - 2943, The upload is
currently signed with key.BedrockKeyConfig but BatchCreate can override the
execution role via request.ExtraParams["role_arn"], so change the code to
resolve an "effective" BedrockKeyConfig (apply the role_arn override from
request.ExtraParams when present) and pass that effective config into uploadToS3
instead of key.BedrockKeyConfig; ensure the same effective config/credentials
used to sign the JSONL upload match the credentials used when submitting the
batch job (BatchCreate/SubmitJob) so uploads and job execution use the same
principal.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/providers/supported-providers/bedrock.mdx`:
- Around line 1733-1738: The Docker example currently includes the `-e
AWS_PROFILE` env var which may confuse readers about per-key profiles; update
the example to either remove `-e AWS_PROFILE` or add a one-line clarifying
comment after the docker command explaining that `-e AWS_PROFILE` is for
process-wide profile selection (used when relying on the default credential
chain) while per-key selection is configured via `bedrock_key_config.profile` in
the AWS Profile / SSO section—reference `-e AWS_PROFILE` and
`bedrock_key_config.profile` in the comment so readers know which to use.

In `@transports/config.schema.json`:
- Around line 2437-2440: The schema currently allows mixing "profile" with
static Bedrock credentials in the "bedrock_key_config" object; change the JSON
schema for bedrock_key_config to forbid combinations by adding a
mutually-exclusive constraint (e.g., use "oneOf" or "anyOf" with explicit
alternatives) so either the profile variant (required "profile" and disallowed
"access_key"/"secret_key") or the static variant (required "access_key" and
"secret_key" and no "profile") is valid; update the bedrock_key_config
definition to include these alternatives and proper "required"/"not" clauses so
the validator rejects configs that include both profile and static keys.

---

Outside diff comments:
In `@core/providers/bedrock/bedrock.go`:
- Around line 2930-2943: The upload is currently signed with
key.BedrockKeyConfig but BatchCreate can override the execution role via
request.ExtraParams["role_arn"], so change the code to resolve an "effective"
BedrockKeyConfig (apply the role_arn override from request.ExtraParams when
present) and pass that effective config into uploadToS3 instead of
key.BedrockKeyConfig; ensure the same effective config/credentials used to sign
the JSONL upload match the credentials used when submitting the batch job
(BatchCreate/SubmitJob) so uploads and job execution use the same principal.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: cf199efb-a7e8-47f3-8603-a40f6fdcb2f7

📥 Commits

Reviewing files that changed from the base of the PR and between 8397278 and ce97aab.

📒 Files selected for processing (17)

• core/providers/bedrock/bedrock.go
• core/providers/bedrock/s3.go
• core/providers/bedrock/signer.go
• core/schemas/account.go
• docs/openapi/schemas/management/providers.yaml
• docs/providers/supported-providers/bedrock.mdx
• framework/configstore/clientconfig.go
• framework/configstore/encryption_test.go
• framework/configstore/migrations.go
• framework/configstore/rdb.go
• framework/configstore/tables/key.go
• framework/configstore/tables/virtualkey.go
• transports/bifrost-http/lib/config.go
• transports/config.schema.json
• ui/app/workspace/providers/fragments/apiKeysFormFragment.tsx
• ui/lib/schemas/providerForm.ts
• ui/lib/types/schemas.ts

[coderabbitai]

🧹 Nitpick | 🔵 Trivial | 💤 Low value

Consider clarifying the Docker example context.

The Docker example shows -e AWS_PROFILE within the AWS Profile / SSO subsection, which documents the per-key profile field. Earlier text (line 678) clearly distinguishes process-wide AWS_PROFILE from per-key bedrock_key_config.profile. While technically correct (both can coexist), showing -e AWS_PROFILE here might confuse readers about whether they need to set both the environment variable AND the profile field when using per-key profiles.

Consider either:

1. Adding a brief comment explaining when to use -e AWS_PROFILE vs the profile field, or
2. Omitting -e AWS_PROFILE from this example since the focus is on per-key profile selection

📝 Example with clarifying comment

docker run -p 8080:8080 \
  -v ~/.aws:/root/.aws:ro \
  -v "$PWD/config.json:/app/config.json" \
  maximhq/bifrost
  
# Note: Add `-e AWS_PROFILE` only if you need process-wide profile selection
# for keys using the default credential chain (authentication method 2).
# Per-key profile selection uses bedrock_key_config.profile instead.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/providers/supported-providers/bedrock.mdx` around lines 1733 - 1738, The
Docker example currently includes the `-e AWS_PROFILE` env var which may confuse
readers about per-key profiles; update the example to either remove `-e
AWS_PROFILE` or add a one-line clarifying comment after the docker command
explaining that `-e AWS_PROFILE` is for process-wide profile selection (used
when relying on the default credential chain) while per-key selection is
configured via `bedrock_key_config.profile` in the AWS Profile / SSO
section—reference `-e AWS_PROFILE` and `bedrock_key_config.profile` in the
comment so readers know which to use.

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Reject mixed profile and static Bedrock credentials in the schema.

Line 2439 documents profile as valid only when access_key/secret_key are empty, but bedrock_key_config currently accepts all three together. That lets config.json bypass the new UI validation and silently fall back to static creds, so the configured profile is ignored.

Proposed schema guard

             "bedrock_key_config": {
               "type": "object",
               "properties": {
                 "access_key": {
                   "type": "string",
                   "description": "AWS access key (can use env. prefix)"
                 },
                 "secret_key": {
                   "type": "string",
                   "description": "AWS secret key (can use env. prefix)"
                 },
                 "session_token": {
                   "type": "string",
                   "description": "AWS session token (can use env. prefix)"
                 },
                 "region": {
                   "type": "string",
                   "description": "AWS region"
                 },
                 "arn": {
                   "type": "string",
                   "description": "AWS ARN"
                 },
                 "role_arn": {
                   "type": "string",
                   "description": "AWS IAM role ARN for AssumeRole (can use env. prefix)"
                 },
                 "external_id": {
                   "type": "string",
                   "description": "External ID for AssumeRole (can use env. prefix)"
                 },
                 "session_name": {
                   "type": "string",
                   "description": "Role session name for AssumeRole (can use env. prefix)"
                 },
                 "profile": {
                   "type": "string",
                   "description": "Named profile from ~/.aws/config or ~/.aws/credentials (including SSO profiles). Used when access_key/secret_key are empty. Composes with role_arn (profile credentials become the source identity for AssumeRole). Can use env. prefix"
                 },
                 "deployments": {
                   "type": "object",
                   "additionalProperties": {
                     "type": "string"
                   },
                   "description": "Model to deployment mappings"
                 },
                 "batch_s3_config": {
                   "type": "object",
                   "description": "S3 bucket configuration for Bedrock batch operations",
                   "properties": {
                     "buckets": {
                       "type": "array",
                       "description": "List of S3 bucket configurations",
                       "items": {
                         "type": "object",
                         "properties": {
                           "bucket_name": {
                             "type": "string",
                             "description": "S3 bucket name"
                           },
                           "prefix": {
                             "type": "string",
                             "description": "S3 key prefix for batch files"
                           },
                           "is_default": {
                             "type": "boolean",
                             "description": "Whether this is the default bucket for batch operations"
                           }
                         },
                         "required": ["bucket_name"],
                         "additionalProperties": false
                       }
                     }
                   },
                   "additionalProperties": false
                 }
               },
+              "allOf": [
+                {
+                  "not": {
+                    "anyOf": [
+                      { "required": ["profile", "access_key"] },
+                      { "required": ["profile", "secret_key"] }
+                    ]
+                  }
+                }
+              ],
               "required": ["region"],
               "additionalProperties": false
             }

As per coding guidelines, transports/config.schema.json is the source of truth for config fields.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	"profile": {
	"type": "string",
	"description": "Named profile from ~/.aws/config or ~/.aws/credentials (including SSO profiles). Used when access_key/secret_key are empty. Composes with role_arn (profile credentials become the source identity for AssumeRole). Can use env. prefix"
	},
	"bedrock_key_config": {
	"type": "object",
	"properties": {
	"access_key": {
	"type": "string",
	"description": "AWS access key (can use env. prefix)"
	},
	"secret_key": {
	"type": "string",
	"description": "AWS secret key (can use env. prefix)"
	},
	"session_token": {
	"type": "string",
	"description": "AWS session token (can use env. prefix)"
	},
	"region": {
	"type": "string",
	"description": "AWS region"
	},
	"arn": {
	"type": "string",
	"description": "AWS ARN"
	},
	"role_arn": {
	"type": "string",
	"description": "AWS IAM role ARN for AssumeRole (can use env. prefix)"
	},
	"external_id": {
	"type": "string",
	"description": "External ID for AssumeRole (can use env. prefix)"
	},
	"session_name": {
	"type": "string",
	"description": "Role session name for AssumeRole (can use env. prefix)"
	},
	"profile": {
	"type": "string",
	"description": "Named profile from ~/.aws/config or ~/.aws/credentials (including SSO profiles). Used when access_key/secret_key are empty. Composes with role_arn (profile credentials become the source identity for AssumeRole). Can use env. prefix"
	},
	"deployments": {
	"type": "object",
	"additionalProperties": {
	"type": "string"
	},
	"description": "Model to deployment mappings"
	},
	"batch_s3_config": {
	"type": "object",
	"description": "S3 bucket configuration for Bedrock batch operations",
	"properties": {
	"buckets": {
	"type": "array",
	"description": "List of S3 bucket configurations",
	"items": {
	"type": "object",
	"properties": {
	"bucket_name": {
	"type": "string",
	"description": "S3 bucket name"
	},
	"prefix": {
	"type": "string",
	"description": "S3 key prefix for batch files"
	},
	"is_default": {
	"type": "boolean",
	"description": "Whether this is the default bucket for batch operations"
	}
	},
	"required": ["bucket_name"],
	"additionalProperties": false
	}
	}
	},
	"additionalProperties": false
	}
	},
	"allOf": [
	{
	"not": {
	"anyOf": [
	{ "required": ["profile", "access_key"] },
	{ "required": ["profile", "secret_key"] }
	]
	}
	}
	],
	"required": ["region"],
	"additionalProperties": false
	}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@transports/config.schema.json` around lines 2437 - 2440, The schema currently
allows mixing "profile" with static Bedrock credentials in the
"bedrock_key_config" object; change the JSON schema for bedrock_key_config to
forbid combinations by adding a mutually-exclusive constraint (e.g., use "oneOf"
or "anyOf" with explicit alternatives) so either the profile variant (required
"profile" and disallowed "access_key"/"secret_key") or the static variant
(required "access_key" and "secret_key" and no "profile") is valid; update the
bedrock_key_config definition to include these alternatives and proper
"required"/"not" clauses so the validator rejects configs that include both
profile and static keys.

[akshaydeo]

Hi @AndreKurait — thanks for the contribution! This PR is currently blocked because our CLA bot shows the Contributor License Agreement as not yet signed. Could you sign it here so we can move this forward: https://cla-assistant.io/maximhq/bifrost?pullRequest=4030

Let us know if you run into any issues signing.