Uploaded image for project: 'Drivers'
  1. Drivers
  2. DRIVERS-2856

Rename OIDC property "PROVIDER_NAME" and config values

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Component/s: Authentication
    • None
    • $i18n.getText("admin.common.words.hide")
      Key Status/Resolution FixVersion
      CDRIVER-5505 Backlog
      CXX-2985 Backlog
      CSHARP-4998 Duplicate
      GODRIVER-3153 Duplicate
      JAVA-5353 Done
      NODE-6002 Gone away
      MOTOR-1274 Duplicate
      PYTHON-4265 Fixed 4.7
      PHPLIB-1407 Backlog
      RUBY-3415 Backlog
      RUST-1877 Gone away
      $i18n.getText("admin.common.words.show")
      #scriptField, #scriptField *{ border: 1px solid black; } #scriptField{ border-collapse: collapse; } #scriptField td { text-align: center; /* Center-align text in table cells */ } #scriptField td.key { text-align: left; /* Left-align text in the Key column */ } #scriptField a { text-decoration: none; /* Remove underlines from links */ border: none; /* Remove border from links */ } /* Add green background color to cells with FixVersion */ #scriptField td.hasFixVersion { background-color: #00FF00; /* Green color code */ } /* Center-align the first row headers */ #scriptField th { text-align: center; } Key Status/Resolution FixVersion CDRIVER-5505 Backlog CXX-2985 Backlog CSHARP-4998 Duplicate GODRIVER-3153 Duplicate JAVA-5353 Done NODE-6002 Gone away MOTOR-1274 Duplicate PYTHON-4265 Fixed 4.7 PHPLIB-1407 Backlog RUBY-3415 Backlog RUST-1877 Gone away

      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.

            Assignee:
            steve.silvester@mongodb.com Steve Silvester
            Reporter:
            matt.dale@mongodb.com Matt Dale
            James Kovacs James Kovacs
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: