Full Report
New AWS Bedrock keys simplify authentication while raising security considerations.
Analysis Summary
# Best Practices: Securing AWS Bedrock API Keys and Authentication Mechanisms
## Overview
These practices address the security implications introduced by the new AWS Bedrock API keys, especially the long-lived variant which defaults to creation via IAM Users. The focus is on mitigating risks associated with long-term credentials, ensuring least privilege, and leveraging modern authentication where possible.
## Key Recommendations
### Immediate Actions
1. **Audit Existing Bedrock API Keys:** Immediately scan your AWS environment for newly created Bedrock API keys (both long-lived `ABSK` prefixed keys and any other credentials associated with Bedrock access).
2. **Restrict IAM User Creation:** If your organization has policies banning the creation of new IAM Users (e.g., via SCPs), ensure these policies are actively enforced, as long-lived Bedrock API keys are created via new IAM Users by default in the console.
3. **Scrutinize Default Policies:** Review all Bedrock API keys created via the console. The default policy, `AmazonBedrockLimitedAccess`, grants over half of Bedrock's privileges, including resource modification (like creating/deleting guardrails). Immediately reduce permissions for any key only intended for model invocation.
### Short-term Improvements (1-3 months)
1. **Implement Expiration for Long-Lived Keys:** When creating long-lived Bedrock API keys, enforce an expiration time via the `CreateServiceSpecificCredential` API call, even though AWS does not enforce it via IAM policy conditions. Aim for the shortest practical lifespan.
2. **Adopt Short-Term Keys for Bedrock:** Prioritize using the new short-term API keys for Bedrock access whenever possible, as they inherently reduce the credential exposure window.
3. **Standardize Credential Management:** Document and enforce the use of the `ABSK` prefix for secret scanning efforts specifically targeting Bedrock API keys, alongside standard methods for finding static access keys.
### Long-term Strategy (3+ months)
1. **Phase Out Long-Lived Credentials:** Develop and execute a roadmap to eliminate all long-lived credentials (including these new Bedrock keys) by migrating application access to short-term, ephemeral methods like IAM Roles via OIDC, Instance Profiles, or temporary security token services whenever feasible for Bedrock interaction.
2. **Establish Central Credential Rotation Policy:** Implement automated processes to rotate all Bedrock API keys (especially those set to never expire) on a defined, aggressive schedule, treating them as high-risk secrets.
3. **Enhance Detection Capabilities:** Update security monitoring and secrets scanning tools to reliably detect keys based on the `ABSK` prefix and the structure of the decoded value (including the embedded IAM username) to ensure broad coverage against primary and secondary keys.
## Implementation Guidance
### For Small Organizations
- **Prioritize Short-Term Keys:** Focus 90% of effort on using the short-term Bedrock API keys or standard IAM roles. Avoid using the console to create keys that result in new IAM Users.
- **Manual Role Assignment:** If a long-lived key is unavoidable temporarily, ensure you manually associate it with an *existing*, purpose-built IAM User that adheres strictly to the principle of least privilege (only `bedrock:InvokeModel` and related read actions).
### For Medium Organizations
- **SCP Enforcement:** Implement Service Control Policies (SCPs) to explicitly deny the creation of new IAM Users (`iam:CreateUser`) across all accounts to block the default creation mechanism for long-lived Bedrock keys.
- **Tool Integration:** Integrate Bedrock API key detection (using the `ABSK` prefix) into existing secrets management and secrets scanning platforms.
### For Large Enterprises
- **Policy Enforcement via Infrastructure as Code (IaC):** Use IaC (e.g., Terraform, CloudFormation) with validation layers (e.g., Sentinel, CloudFormation Guard) to prevent the deployment of any resource configurations that result in long-lived Bedrock API keys without mandatory expiration and restrictive permissions policies.
- **Automated Remediation:** Create automated workflows to detect keys created outside of the IaC process, automatically revoke them, and alert the responsible team, especially for keys granted broad `AmazonBedrockLimitedAccess`.
## Configuration Examples
**Configuration Note:** The article implies that long-lived Bedrock API keys use the IAM API `CreateServiceSpecificCredential` and can be manually associated with an existing IAM user.
| Aspect | Configuration Detail | Rationale |
| :--- | :--- | :--- |
| **Key Generation API** | `CreateServiceSpecificCredential` | This is the underlying API used for Bedrock API key creation. |
| **Expiration Setting** | Set an explicit expiry date in the API call. | Although not enforced by IAM policy conditions, setting a TTL reduces risk. |
| **Detection Signature (Prefix)** | `ABSK` | Use this prefix for secret scanning tools to identify these specific keys reliably. |
| **Detection Detail (Decoded)** | Check for `BedrockAPIKey` within the decoded string. | Useful for identifying ownership context (IAM User name embedded). |
## Compliance Alignment
While Bedrock API keys are new, their use of IAM entities and long-lived credentials connects them to existing standards:
- **NIST SP 800-53 (AC/IA series):** Relates to Access Control and Identification/Authentication, specifically focused on credential lifecycle management and least privilege enforcement.
- **ISO 27001 (A.9.2):** Focuses on the proper management of user access and authentication information, particularly mandatory rotation and timely revocation.
- **CIS AWS Foundations Benchmark:** Directly aligns with security controls discouraging the use of static, long-lived access keys in favor of role-based or temporary credentials.
## Common Pitfalls to Avoid
1. **Assuming "Limited Access" is Truly Limited:** Do not trust the `AmazonBedrockLimitedAccess` policy name. Verify its actual permissions (it grants significant privileges) and reduce scope aggressively.
2. **Ignoring the IAM User Creation:** Failing to block IAM User creation via SCPs means the easiest mechanism for creating long-lived, high-risk keys remains exploitable by privileged developers/CI/CD pipelines.
3. **Relying Solely on Standard Access Key Scanning:** Since Bedrock API keys use a unique `ABSK` prefix, relying only on scans for standard `AKIA...` style keys will miss these new long-lived secrets.
4. **Inconsistent Expiration Enforcement:** Creating a key with an expiration date in the API call but not enforcing its actual usage or rotation centrally creates a false sense of security if the credential outlives its intended purpose.
## Resources
- **AWS IAM API Documentation:** Consult the documentation for `CreateServiceSpecificCredential` for parameter details, especially concerning optional expiration settings. (Defanged link structure for reference: `aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html`)
- **AWS Bedrock Documentation:** Reference the official guide on how to use the keys via the HTTP header method. (Defanged link structure for reference: `aws.amazon.com/bedrock/latest/userguide/api-keys-use.html`)
- **Wiz Blog Post (Source Context):** Refer to the original analysis for deeper technical decoding details regarding the key structure. (Defanged link structure for reference: `wiz.io/blog/a-new-type-of-long-lived-key-on-aws-bedrock-api-keys`)