Summary

The current built-in integration configuration pattern for the MONGODB-OIDC auth mechanism is not granular enough to unambiguously describe what mechanism drivers should use to fetch OIDC access tokens. The current supported values are "aws", "azure", and "gcp". However, each of those public clouds have many different mechanisms used to fetch OIDC access tokens, depending on the hosted application environment used. For example, there are 6 different mechanisms for fetching an OIDC access tokens for Azure environments (see here for more details).

We should change the config values to more specifically identify the mechanism drivers should use to fetch OIDC access token. The initial set should be:

• "azure-imds" - Supports Azure VM and any other environment that provides OIDC access tokens via the Azure Instance Metadata Service
• "gcp-imds" - Supports GCP Compute Engine and any other environment that provides OIDC access tokens via the GCP Instance Metadata Service

The eventual set may also include:

• "k8s" - Supports self-hosted Kubernetes and EKS (AWS), AKS (Azure), and GKE (GCP) hosted Kubernetes environments.
• "azure-obo" - Supports the Azure On-Behalf-Of auth flow in various Azure environments.

With the updated config values, the auth mechanism property PROVIDER_NAME also becomes a misnomer, because it no longer describes an OIDC Identity Provider, but describes the environment of the application. We should rename that to OIDC_ENV to prevent confusion between the driver-side and server-side configurations.

See the original proposal doc for more rationale and context.

Motivation

Who is the affected end user?

• Customers who want to configure OIDC auth in their applications.
• Drivers devs.

How does this affect the end user?

The less specific configuration values means drivers would need to automatically detect the hosted environment to figure out how to fetch OIDC access tokens. That automatic driver logic is more prone to bugs or unexpected edge cases compared to more explicit configuration and may lead to OIDC access tokens being pulled from unexpected sources.

For customers that means their application authentication may not work as expected (e.g. if there are multiple sources for OIDC access tokens and the driver automatically picks the wrong one).

For drivers devs, that means more bug tickets. That's especially problematic for auth logic because the information involved is sensitive, making it more difficult to debug.

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

For the small initial set of built-in OIDC environment integrations, the probability is low. However, as the number of built-in integrations increases, the probability of ambigouous logic or unexpected behavior will increase. It also makes drivers more sensitive to unexpected changes in the application environment (e.g. different environment variables being set).

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

The customer's application may stop working, or have different permissions than expected.

Is this issue urgent?

Yes. These are breaking changes, so we need to make them before any driver releases a stable version with MONGODB-OIDC support.

Is this ticket required by a downstream team?

No.

Is this ticket only for tests?

No.

Acceptance Criteria

• Rename the MONGODB-OIDC auth mechanism property PROVIDER_NAME to OIDC_ENV, including in the Auth spec and all spec tests.
• Update the PROVIDER_NAME values (now OIDC_ENV) from "azure" to "azure-imds" and from "gcp" to "gcp-imds". Remove support for "aws".
• Replace the "AWS" built-in integration with a "Test" built-in integration. The test integration may use the same logic variable as the existing "AWS" built-in (i.e. the same environment variables) or may update it to a more test-specific naming.
  • If the "Test" integration changes the environment variables used, also update the corresponding scripts in drivers-evergreen-tools.