[receiver/mongodb] Add support for auth_mechanism, auth_mechanism_properties and auth_source configuration

[hardik-choksi]

Description

Adds configuration options for MongoDB authentication mechanism, source database, and mechanism properties to the MongoDB receiver. This allows users to specify authentication methods like SCRAM-SHA-256, GSSAPI (Kerberos), or MONGODB-AWS when connecting to MongoDB instances that require specific authentication mechanisms. The implementation adds three new optional configuration fields:

• auth_mechanism: The authentication mechanism to use (e.g., SCRAM-SHA-1, SCRAM-SHA-256, GSSAPI, MONGODB-AWS, MONGODB-X509)
• auth_source: The database name to use for authentication (defaults to admin if not specified)
• auth_mechanism_properties: A map of key-value pairs specifying additional properties for the authentication mechanism (e.g., SERVICE_NAME for GSSAPI, AWS_SESSION_TOKEN for MONGODB-AWS)

These fields are applied to both primary and secondary MongoDB connections when connecting to replica sets, ensuring consistent authentication configuration across all connections.

Link to tracking issue

Fixes #40686

Testing

• Added new test TestOptionsWithAuthMechanismAndSource to verify authentication configuration (including auth_mechanism, auth_source, and auth_mechanism_properties) is correctly applied to both primary and secondary connections
• Updated TestLoadConfig to verify configuration loading from YAML with the new fields
• All existing tests pass
• Verified linting (make lint) and formatting checks pass
• Tested that auth_mechanism, auth_source, and auth_mechanism_properties are properly set in MongoDB client options when provided

Documentation

• Updated README.md to document the new auth_mechanism, auth_source, and auth_mechanism_properties configuration options with usage examples
• Updated testdata/config.yaml to include example usage of the new configuration fields
• Added changelog entry describing the enhancement for users

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: hardik-choksi / name: Hardik Choksi (3cfa7f2, 5a09f1f, 5ae2634, 76ee5e5, ae79a58, f60b058)

[github-actions]

Welcome, contributor! Thank you for your contribution to opentelemetry-collector-contrib.

Important reminders:

• Please review our Contributing Guidelines.
• Don't forget to sign the Contributor License Agreement (CLA) if you haven't already.

A maintainer will review your pull request soon. Thank you for helping make OpenTelemetry better!

[dyl10s]

We shouldn't be requiring a username and password for all authentication types.

[hardik-choksi]

Good catch! I've updated the code to allow authentication setup when only auth_mechanism is specified, even without username/password.

Changes made:

• Modified the condition to set up auth credentials when either username/password are provided OR when auth_mechanism is specified
• Added test case TestOptionsWithAuthMechanismOnly to verify X509 authentication works without username/password

[dyl10s]

This is looking good to me, just some CI issues to fix up. After that, I will give it one final test before approving!

[hardik-choksi]

This is looking good to me, just some CI issues to fix up. After that, I will give it one final test before approving!

I've fixed the CI issues. Checks should pass after workflows are approved. Also, apologies for all the extra reviewers and labels that got added - the branch got messy from multiple merges with main. I've cleaned it up by rebasing onto the latest main. The extra reviewers/labels can be removed at your convenience.

[dyl10s]

2 minor things, I tested everything and it's working well. I will be ready to give this my approval once these last comments are addressed.

[dyl10s]

Can you add a link to the Go documentation that explains how to configure each of these, or include a section in this readme on how to configure them

[hardik-choksi]

Yeah, I'll add links to documentation in a separate Auth section.

[dyl10s]

Looks like for X509, some additional work is needed around appending to the connection string

https://pkg.go.dev/go.mongodb.org/mongo-driver/v2/mongo#example-Connect-X509

Feel free to add support for this or remove the option for now.

[hardik-choksi]

I tested X.509, SCRAM-SHA-256, and SCRAM-SHA-1 using dockerized MongoDB 7.0 instances and confirmed they all work correctly with the receiver.

For X.509, the receiver already works without any connection string modifications. The MongoDB Go driver example puts TLS certificates in the URI:

mongodb://host:port/?tlsCAFile=ca.pem&tlsCertificateKeyFile=client.pem

But since the receiver uses OTel's standard configtls.ClientConfig, users configure TLS via the tls block instead (which is consistent with all other OTel components):

receivers:
    mongodb:
        hosts:
          - endpoint: localhost:27018
        auth_mechanism: MONGODB-X509
        auth_source: $external
        tls:
          ca_file: /path/to/ca.pem
          cert_file: /path/to/client-cert.pem
          key_file: /path/to/client-key.pem

The only difference from the Go driver examples is that OTel's TLS config uses separate cert_file and key_file instead of a single combined PEM. If users have a combined PEM, they can split it with:

openssl x509 -in client.pem -out client-cert.pem
openssl pkey -in client.pem -out client-key.pem

I verified this works with a dockerized MongoDB 7.0 instance using self-signed X.509 certificates.

For MONGODB-AWS and GSSAPI: these mechanisms require specific server-side support (Atlas/Percona for AWS, MongoDB Enterprise for GSSAPI) so I couldn't test them with a standard Docker image. However, the receiver passes auth_mechanism and auth_mechanism_properties directly to the Go driver's Credential struct via SetAuth(), so they should work as expected.

Also, I added PasswordSet support for GSSAPI (Kerberos) password-based authentication, following the Go driver documentation.

This has not been tested end-to-end, as GSSAPI requires MongoDB Enterprise.

[dyl10s]

LGTM, thank you for this contribution!

[axw]

Nice!

[otelbot]

Thank you for your contribution @hardik-choksi! 🎉 We would like to hear from you about your experience contributing to OpenTelemetry by taking a few minutes to fill out this survey. If you are getting started contributing, you can also join the CNCF Slack channel #opentelemetry-new-contributors to ask for guidance and get help.