Hi all, Following up on the suggestion from the discussion here <https://github.com/apache/polaris/issues/1929#issuecomment-3045487786> — thank you for the feedback so far.
We’re currently migrating our self-hosted Polaris service from version 0.9 (EclipseLink-based metastore) to version 1.0 (JDBC-based metastore). As part of this transition, we need to preserve the existing `clientId` and `clientSecret` credentials for registered principals. These credentials are already embedded in customer workflows. Rotating them during migration would create disruptions and require cross-team coordination with clients — making both rollout and rollback significantly more complex. We understand the security implications of allowing arbitrary credentials to be passed in an API request. That said, we believe this capability can be introduced safely and in a tightly controlled manner. For example: - Restricting this functionality to service admin only. - Ensuring all credential transmissions occur only over HTTPS - Clearly documenting that this is strictly for *migration/bootstrap use cases*, not for production use - Disabling this functionality by default in publicly hosted deployments - Ensuring credentials are never logged (e.g., in observability systems like logs or traces) Our goal is not to weaken the system's security guarantees, but to provide a practical and secure migration path where credential continuity is essential. Since there are a lot of DB schema changes involved, Manual insertion into the metastore isn't ideal either, due to potential inconsistencies in hashing or salting logic across versions — increasing operational risk. *### Proposal* We propose extending the existing `createPrincipal` API to optionally accept `clientId` and `clientSecret` fields, with the above safeguards in place. We would appreciate your feedback on this proposal and are happy to contribute a patch once there’s alignment. We’re also open to discussing this during the next Polaris Community Sync if helpful. Arun Suri Senior Software Engineer He/him/his Engineering | Fivetran arun.s...@fivetran.com fivetran.com <//fivetran.com> <http://www.fivetran.com> [image: facebook] <https://www.facebook.com/Fivetran/> [image: twitter] <https://twitter.com/fivetran?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor> [image: linkedin] <https://www.linkedin.com/company/fivetran> [image: instagram] <https://www.instagram.com/fivetran_ig/>
