[DRIVERS-1941] Add MONGODB-AWS Support for EKS Service Account Auth Created: 04/Oct/21  Updated: 01/Feb/22  Resolved: 01/Feb/22

Status: Closed
Project: Drivers
Component/s: Authentication
Fix Version/s: None

Type: Spec Change Priority: Unknown
Reporter: Kekoa Vincent Assignee: Unassigned
Resolution: Duplicate Votes: 0
Labels: driver
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates DRIVERS-2011 On-demand callback for AWS credentials Closed
Related
related to DRIVERS-2011 On-demand callback for AWS credentials Closed
is related to DRIVERS-1746 Add native support for AWS IAM Roles ... Closed
Driver Changes: Needed

 Description   

Summary

For the MONGODB-AWS authentication mechanism, provide native driver support for obtaining AWS credentials using the preferred method of assigning Kubernetes Service Accounts to workloads. Currently, the driver requires a manual STS token assume for EKS to happen outside of the driver. This is not only a usability issue but creates bugs with regard to the token lifetimes in failure scenarios.

Relevant Section in Specification: Auth MONGODB-AWS Obtaining Credentials
Affordances are already given for ECS, EC2, and Lambda runtimes. EKS is another key runtime that should be more fully supported.

Motivation

Who is the affected end user?

AWS EKS users who are using the AWS IAM Passwordless Authentication for Atlas.

How does this affect the end user?

More code is required to authenticate outside of the driver for EKS. This involves rebuilding a connection string and creates special case code when deploying within EKS vs any other normal deployment. This increases configuration for end user apps and introduces places for bugs and misconfiguration.

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

For any EKS users who would like to increase security by using AWS IAM roles to eliminate secrets, they will run into this issue.

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

Failure scenarios when a connection drops and a reconnection is initiated will fail due to an expired token. This can mean applications are required to crash and restart in order to obtain valid credentials, or complex error handling will need to be implemented.

As far as the usability issue, the problem occurs for every user who needs to figure out how to accomplish this authentication. Manual STS token assumption is an additional burden placed on every user within EKS.

Is this issue urgent?

This issue is not urgent, but the problem is significant enough to deter usage of passwordless IAM authentication which would increase end user deployment security.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No.



 Comments   
Comment by Alexander Golin (Inactive) [ 25/Jan/22 ]

james.kovacs anyone in particular we should solicit a thumbs up from re: your comment above? Otherwise sounds like we can close out!

Comment by Kekoa Vincent [ 08/Oct/21 ]

We have submitted a PR to the Go driver to share our solution and submit it for your consideration to implement similar fixes on all drivers. https://github.com/mongodb/mongo-go-driver/pull/766/files 

Comment by Kevin Albertson [ 07/Oct/21 ]

Thank you for the detailed description and PR kevincent@tradestation.com

Comment by Kekoa Vincent [ 04/Oct/21 ]

Also opened PR at https://github.com/mongodb/specifications/pull/1075 .

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