Current Limitation
When configuring an AWS Bedrock endpoint for an AI API, the gateway can only authenticate to AWS using static, long-lived access keys - an AWS Access Key ID and Secret Access Key that must be entered in the Publisher and stored (encrypted) by APIM.
This has two significant drawbacks:
1. No support for IAM role assumption (STS AssumeRole).
There is no way to configure the endpoint to assume an IAM role. Users who follow AWS best practices - where a base identity assumes a scoped, often cross-account role (with an optional external ID) to access Bedrock - cannot do so. They are forced to create and embed long-lived keys for the target permissions instead.
2. No support for environment / runtime credentials.
When the gateway runs on VM or Kubernetes infrastructure, it cannot use the credentials the platform already provides.
Because static keys are the only option, users must generate and store long-lived secrets even when the runtime could supply short-lived, auto-rotating credentials with no secrets at all.
Impact: long-lived AWS secret keys must be created and stored in APIM for every Bedrock endpoint, which is harder to rotate, less secure, and inconsistent with standard practices that customers expect to use in production deployments.
Suggested Improvement
Extend the AWS Bedrock endpoint configuration to support two additional authentication modes on top of the existing static access/secret keys, so the gateway can authenticate to AWS the way AWS best practices recommend — ideally without any long-lived secrets stored in APIM.
- STS AssumeRole
Allow an endpoint to assume an IAM role to obtain temporary credentials for the Bedrock call:
- New Publisher option "Enable STS AssumeRole" exposing Role ARN, Role Region, and an optional External ID.
- The gateway uses the base identity (stored keys, or the environment identity below) to call AWS STS AssumeRole, then signs the Bedrock request with the returned short-lived credentials (including the session token).
- Supports the common cross-account / least-privilege pattern with an external ID.
- Environment credentials
Allow an endpoint to resolve credentials from the gateway's runtime instead of storing any keys:
- New Publisher option "Use environment credentials"; when enabled, the Access Key / Secret Key fields are hidden and not required.
- The gateway resolves credentials via the AWS SDK default provider chain, which transparently covers:
- VMs
- Kubernetes
- and, where configured, environment variables / shared profile / ECS container credentials.
- Assume-role (mode 1) can be layered on top of the environment identity.
Version
4.7.0
Current Limitation
When configuring an AWS Bedrock endpoint for an AI API, the gateway can only authenticate to AWS using static, long-lived access keys - an AWS Access Key ID and Secret Access Key that must be entered in the Publisher and stored (encrypted) by APIM.
This has two significant drawbacks:
1. No support for IAM role assumption (STS AssumeRole).
There is no way to configure the endpoint to assume an IAM role. Users who follow AWS best practices - where a base identity assumes a scoped, often cross-account role (with an optional external ID) to access Bedrock - cannot do so. They are forced to create and embed long-lived keys for the target permissions instead.
2. No support for environment / runtime credentials.
When the gateway runs on VM or Kubernetes infrastructure, it cannot use the credentials the platform already provides.
Because static keys are the only option, users must generate and store long-lived secrets even when the runtime could supply short-lived, auto-rotating credentials with no secrets at all.
Impact: long-lived AWS secret keys must be created and stored in APIM for every Bedrock endpoint, which is harder to rotate, less secure, and inconsistent with standard practices that customers expect to use in production deployments.
Suggested Improvement
Extend the AWS Bedrock endpoint configuration to support two additional authentication modes on top of the existing static access/secret keys, so the gateway can authenticate to AWS the way AWS best practices recommend — ideally without any long-lived secrets stored in APIM.
Allow an endpoint to assume an IAM role to obtain temporary credentials for the Bedrock call:
Allow an endpoint to resolve credentials from the gateway's runtime instead of storing any keys:
Version
4.7.0