When AWS first launched two decades ago, the only way of authenticating applications was through long-lived access keys. Over the years AWS has created various options for short-term credentials which are a big improvement for security because they reduce the likelihood that they will be found by an attacker during their lifespan.  AWS recently summarized many of these options in a blog post and I’ve discussed these different forms of authentication in my own post.  So it was surprising to see that AWS has created a new form of long-term keys: Bedrock API keys. This blog will look more in-depth at this new type of long-term API key as well as at a new type of short-term API key created for Bedrock.

Long-term Bedrock API keys

In the AWS web console, choosing between short and long term Bedrock API keys looks very similar, but they use very different mechanisms behind the scenes.

Creating a long-term Bedrock API key results in the creation of a new IAM User when done through the web console.  You can also manually create one of these keys by associating it with an existing IAM User.  Although the continued use of IAM Users for this feature at first does not seem ideal, it does mean that AWS associated a new risky feature with an old risky feature.  As a result, for companies that have already banned IAM Users via SCP, they have already banned this new feature.  The SCP for preventing the creation of IAM Users was shown in one of our previous blog posts: Setting secure defaults on AWS and avoiding misconfigurations.

The new IAM User will be created with a name like “BedrockAPIKey-abcd” where the last 4 letters are random.  This user then has the IAM policy AmazonBedrockLimitedAccess automatically added to it.  Even though this policy is named with the word “limited”, it still has over half of the Bedrock service’s privileges, including the ability to create and delete guardrails. For most use cases, this credential should only be used for invoking models and perhaps some view-only privileges, so these keys will be over-privileged for most use cases when created through the web console.

Instead of using an IAM User access key, Bedrock API keys are created using the IAM API CreateServiceSpecificCredential, which is an old API from 2016 that previously was only used for CodeCommit and Amazon Keyspaces (for Apache Cassandra).  New functionality was added to that API for these new keys so that they can have an expiration time set on them, or never expire.  I like that AWS did provide a way to have an expiration time, but there is not a way to enforce an expiration time on these using IAM policy conditions.  

These new API keys look like this: ABSKQmVkcm9ja0FQSUtleS… They are 132 characters, with the prefix ABSK, and then a base64 encoded string.  When decoded, that string will look like “BedrockAPIKey-abcd+1-at-123456789012:FS0k7F…”   So the previously given example “ABSKQmVkcm9ja0FQSUtleS” decodes to the “BedrockAPIKey” prefix and thus can be used for secret scanning to find these with minimal false positives.  Of course the usual caveats apply that this is not documented by AWS and thus subject to change. Additionally, as mentioned these Bedrock API keys can be associated with existing IAM Users that have different usernames, so to broadly detect these you should unfortunately use only the “ABSK” prefix.

The decoded string contains the associated IAM User name, whether this is the primary or secondary API key, and the account ID. You can have two Bedrock API keys per IAM User, similar to access keys, and the second key will be denoted with the “+1” in that decoding.  After the colon, there is another base64 encoded string, but that decodes to 44 bytes of apparently random binary data.

To use these API keys you simply add an HTTP header that contains it, as shown in a one line curl request in the AWS docs here.  This is different from most authentication to AWS which uses an algorithm called sigv4 that involves hashing and as a result the secret key is never sent.  With this Bedrock API key, it is copied directly into the HTTPS request. The request is made over TLS, but it is surprising for AWS to be using a bearer token as opposed to their usual hashing mechanism.

Long-term Bedrock API keys are already leaking

These long-term API keys are already showing up in public GitHub repositories. We first observed leaked keys there within two weeks of the launch.

We recommended to AWS that these keys should be integrated into the Github Secret Scanning partner program which is what AWS uses to identify IAM User access keys that are published to public GitHub repositories. As of August 1st, these keys are now identified as part of that so that when a long-term Bedrock API key is committed to a public GitHub repo, AWS will apply their quarantine policy to the IAM User, and notify the customer via a support case, as well as an email to the root email account. These communications share information about the exposed credential, including the repo, commit, and file, along with the IAM User name.

Wiz has also integrated detection of these keys into our own secret scanner.

Short-term Bedrock API keys

Short-term Bedrock API keys are used in the same way as the long-term keys (as bearer tokens in HTTPS requests), but they are generated through a completely separate mechanism.  These short-term keys are over 1000 characters long and look like “bedrock-api-key-YmVkcm9jay…”

Whereas the long-term credentials are created via the API call iam:CreateServiceSpecificCredential, the short-term credentials do not have an API call to create them.  Instead, AWS released a new library for creating them.  You can see in the code that all this does is create a presigned URL, base64 encode it, and prefix it with that string “bedrock-api-key-”.  Because this is making a pre-signed URL, there is no CloudTrail event for the creation of these short-term keys because it is all happening client-side. Therefore, these will only be logged in CloudTrail when they are used.  The API that is being signed is a new undocumented API bedrock:CallWithBearerToken.

Detecting these in CloudTrail logs

The creation of the long-term Bedrock keys can be spotted by looking for events from iam:CreateServiceSpecificCredential with requestParameters.service=="bedrock.amazonaws.com".  The creation of the short-term Bedrock keys is not recorded in CloudTrail because it is done client-side through the creation of a presigned-URL. 

The usage of either long-term or short-term Bedrock keys can be identified due to the inclusion of "additionalEventData": { "callWithBearerToken": true } in the event.  Determining whether this was due to a long-term or short-term Bedrock key is based on the type of principal: IAM Users use long-term keys, and IAM Roles use short-term keys.

Closing thoughts

AWS created this new feature “to simplify the getting started experience and accelerate generative AI development”.  It reduces some of the complexity of other authentication mechanisms, but otherwise was an unexpected addition, given that long-lived credentials are a constant source of security incidents for AWS customers.  These new credential types are each based on some pre-existing AWS capabilities, so in some ways they are being built on an existing, and well tested security foundation, but they also added the simpler bearer token concept to AWS.  These new API keys can only be used with Bedrock, so they are limited in how they can be abused, but Bedrock is one of the services that AWS’s quarantine policy makes an attempt at restricting due to abuse of that service in the past by attackers.  

All things considered, we still recommend implementing the SCP to prevent IAM Users (and thus long-term Bedrock API keys), and additionally to deny the privilege bedrock:CallWithBearerToken (as shown here) which will prevent the use of either long or short-term Bedrock keys.  Using Bedrock can still be accomplished through other pre-existing authentication mechanisms.

Statement from AWS

---
AWS can confirm that the Secrets Scanning process has already been updated to include Amazon Bedrock API keys, no action from customers is required. The issue identified in the blog post occurred before the expansion of our scanning process. AWS also investigated Bedrock API keys that had previously been committed to GitHub and quarantined them where found.

If we detect that an account may have been inappropriately accessed, AWS will notify the customer and work with them to secure their account. You can find information on handling compromised Amazon Bedrock keys in the Amazon Bedrock API guide and alternatives to long-term access keys in the IAM User Guide.

We thank WIZ for engaging AWS Security and look forward to collaborating on future reports.
---