Visitar URL original
Credential Rotation · Issue #58475 · apache/spark · GitHub
Skip to content

Credential Rotation #58475

Open
Open

Description

@tmaoz

Hello,

In my company we are building an internal platform that runs many ETL processes over Spark 4.1 with PySpark and spark-connect.
We are using an AWS RDS Postgres DB as well as custom Postgres deployments for usage with AGE etc., all read/write via Spark.
We would like to have an option to change the credentials for connections where the pipeline configuration is coming from config files we have that are dynamically translated into Spark code.
For writers this is not a problem as we can add our own retry mechanism that recreates the writer with the updated credentials.
However, For readers, this is a problem because at the point of materialization, the reader is already baked into the pipeline with the original credentials and it does not have any way to change the credentials without restarting the entire ETL process, which could be running for several hours before the plan reaches the point where it needs to use the JDBC connection.

I'm wondering if it would be possible to add some way of reconfiguring just the reader/writer credentials from PySpark code without having to write dedicated Java code, compile into a JAR and load when running Spark?

Thanks!

Activity

  1. konjac commented on Sep 17, 2026

    @konjac

    The problem does not seem to be Spark-specific, but rather a general reader/writer integration scenario (not necessarily Spark) involving connection credentials.

  2. CoderNasim2023 commented on Oct 5, 2026

    @CoderNasim2023

    Hi, I am interested in investigating this issue. I understand the problem as a credential-rotation gap for long-running JDBC reads, where credentials are captured when the reader is created but may expire before execution/materialization.

    Before proposing an implementation, could you clarify the preferred scope?

    1. Should credential refresh happen during JDBC connection creation for each partition/task?
    2. Should Spark accept a credential provider or callback instead of static JDBC options?
    3. Should the reader retry with refreshed credentials after an authentication failure?
    4. Is the expected solution specific to Spark JDBC, or should it be designed for other DataSource V2 integrations as well?

    I would like to first confirm the expected API and retry semantics with the maintainers before preparing a PR. @tmaoz

  3. CoderNasim2023 commented on Oct 7, 2026

    @CoderNasim2023

    May I start on working on it ? @tmaoz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions