Skip to content

Conversation

danielgerlag
Copy link
Contributor

This pull request introduces support for authenticating to Azure PostgreSQL databases using Azure Identity (Microsoft Entra Workload ID) in both the Debezium reactivator and SQL proxy components. It also updates several dependencies and adds logic to select authentication mode based on configuration.

Azure Identity Integration:

  • Added AzureIdentityTokenFetcher and AzureIdentityPostgreSQLConnection classes to fetch Azure AD tokens and establish PostgreSQL connections using Azure Identity, enabling managed identity authentication. [1] [2]
  • Updated the Debezium reactivator (PostgreSql.java) and SQL proxy (ResultStream.java) to use Azure Identity for authentication when IDENTITY_TYPE is set to MicrosoftEntraWorkloadID, including setting the token as the database password and enforcing SSL. [1] [2]

Dependency Updates:

  • Upgraded debezium from 2.7.3.Final to 3.2.2.Final and azure-identity from 1.9.2 to 1.18.0 in relevant Maven files for compatibility with Azure Identity features. [1] [2] [3]
  • Updated PostgreSQL JDBC driver from 42.7.4 to 42.7.8 for the SQL proxy.

Configuration Improvements:

  • Added error retry configuration (errors.max.retries) to the Debezium connector setup for improved reliability.

YAML Spec Simplification:

  • Removed password and user fields from the default source provider spec, reflecting the move to token-based authentication for Azure.

@danielgerlag danielgerlag requested a review from a team as a code owner September 25, 2025 21:55
- database
- host
- port
- password
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we make user and password optional here along with identity block, and make the mgmt_api enforce that atleast one of them is present?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should avoid making global assumptions about how all sources should work in the Management API. Ideally we want to offload this validation to the implementor of each source.

.build();
.with("snapshot.mode", "no_data");

String identityType = SourceProxy.GetConfigValue("IDENTITY_TYPE");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we reconsider (maybe in a separate PR) adding fields to source-provider instead of relying on undocumented environment variables like IDENTITY_TYPE ?

Should the SDK provide a better way of achieving this? I worry that we're not using the schema-driven approach properly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have varying degrees of support for abstracting that environment variable across our SDKs, I think the .net version has this. We also do not yet have any documentation on building a source, I think that would be the place to document these. Could you clarify what you mean by "schema-driven approach"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By schema-driven I meant that source-provider defines the schema of the Source Config, so it can drive what fields are supported in the config.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The identity type is a higher level field in the YAML that is applicable to all sources / reactions. The config schema is set for the configuration section, which is specific per component.

@danielgerlag danielgerlag merged commit fb63882 into drasi-project:main Oct 8, 2025
73 of 74 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants