[DRIVERS-2179] Add support for updating expired AWS KMS temporary access credentials using assumed roles in FLE Created: 28/Jan/22  Updated: 08/Jan/23  Resolved: 08/Jan/23

Status: Closed
Project: Drivers
Component/s: Client Side Encryption
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Cynthia Braund (Inactive) Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: FLE
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on MONGOCRYPT-382 Support on-demand credentials Closed
Duplicate
duplicates DRIVERS-2280 Obtain AWS credentials for CSFLE in t... Closed
Related
related to CDRIVER-4276 On-demand Credentials Callback for CSFLE Closed
related to DRIVERS-2011 On-demand callback for AWS credentials Closed
Driver Changes: Needed
Quarter: FY24Q1
Case:

 Description   

Summary

Currently, the FLE KMS support includes support for AWS temporary access keys. These temporary keys can be obtained via AssumeRole, from EC2 machines that have been assigned a role, and a few other means. Temporary credentials always expire after some time and libmongocrypt provides no way for users to refresh their credentials.

Motivation

Who is the affected end user?

FLE customers using assumed roles for AWS KMS

How does this affect the end user?

If a user configures the FLE KMS support for AWS temporary credentials then their MongoDB driver will stop working upon expiration. For instance, if the temporary credentials have a timeout of 6 hours, then the driver will error after 6 hours. This is the problem the customer is hitting. The user has no recourse but to restart their usage of MongoDB drivers (i.e. restart their app), providing the new, valid credentials.

How likely is it that this problem or use case will occur?

Main path as having expiring credentials is a key component of the assumed roles functionality.

If the problem does occur, what are the consequences and how severe are they?

Driver will stop being able to access encryption key and therefor no encryption of decryption can happen.  The user will need to restart, as outlined above.

Is this issue urgent?

The customer is currently experiencing this issue and has opened a support ticket.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No

Description from Mark Benvenuto
The fix is to provide a way for users to provide fresh credentials. Since users can acquire their credentials in a variety of ways, it is difficult for libmongocrypt to reacquire them the same way as the user originally done. Instead, it is easier if the user simply provides a function that can fetch the credentials as needed.
===================
Work outlined

  • Participants:
  • libmongocrypt
  • Java driver
     
    libmongocrypt
    --------------------
    libmongocrypt adds a callback like:
     

int libmongocrypt_set_credentials_callback(int(credentials_callback)(char** buf, int* len))

where

int(credentials_callback)(char** buf, int* len)
returns 0 on success and 1 on failure
on success, it sets buf and len to point to a buffer then contains a BSON document that represents the credentials of:

{
 accessKeyId : string
 secretKey: string,
 sessionToken: string
}

 
Java driver
---------------
Java driver updates the libmongocrypt java bindings  to support this method and adds a way for the user to set this callback in the Java driver.
===============

 



 Comments   
Comment by Kevin Albertson [ 08/Jan/23 ]

This is resolved by DRIVERS-2280.
Drivers implementing DRIVERS-2280 support configuring the AWS KMS provider with an empty document: `aws: {}`.
The AWS credentials are obtained when needed following the logic for MONGODB-AWS authentication mechanism.

Comment by Bernie Hackett [ 28/Jan/22 ]

I assume, like many other AWS credentials problems, this can be solved with DRIVERS-2011.

Generated at Thu Feb 08 08:24:55 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.