Hi all, +1 to resuming the remote signing work now, rather than waiting for the spec on refreshing auth data. Alex asked on the issue (#32) for our use case, so here it is.
We run Polaris against an on-prem S3-compatible store (a FlashBlade). Its STS support is limited to AssumeRoleWithWebIdentity, so Polaris cannot vend credentials through its current AssumeRole flow. As a result we turn vending off and distribute static storage keys to every service in every environment: Polaris, Trino, Spark (table maintenance), and PyIceberg and DuckDB clients. That is a rotation and blast-radius burden that grows with each environment we add. Remote signing would remove the static keys from the clients, which is why we would like to see it move. On the auth-refresh gap: our workloads are mostly short queries and pipeline runs, and our longest jobs are Spark maintenance operations that take minutes, so as far as we can tell we could start without refresh support and pick it up incrementally, as Alex suggested. Client versions are mixed on our side (Trino on Iceberg 1.12, Spark on the Iceberg 1.10 runtime, PyIceberg and DuckDB with their own Iceberg implementations), so we expect client-side support to vary. We would be happy to test early builds against FlashBlade and report which engines and versions work. (On #32 we also described a smaller option, AssumeRoleWithWebIdentity as an alternative STS flow. Remote signing is the fuller fix and the one we would rather see.) Best, Tommy On 2026-10-02 15:00 UTC Alex Dutra wrote: > Hi all, > > Polaris will soon be updated to Iceberg 1.12. > > This release includes the new remote-signing-config field within > LoadTableResult, which addresses nearly all remaining requirements for > Polaris to complete its remote signing implementation, abandoned a > while ago due to impending spec changes. > > However, one detail remains: when we added the remote-signing-config > structure, refreshing the contained authentication or authorization > data was intentionally left out of scope. I plan to start a separate > discussion and spec change proposal with the Iceberg community > regarding this shortly. > > Despite this, the core remote signing functionality is again viable in > Polaris today, with Iceberg 1.12. The only missing piece being that > auth data cannot be refreshed yet, though this capability could be > added incrementally in a future update. > > With that in mind, I would like to ask the Polaris community: > > Should we resume the remote signing work where we left [1]? Or would > it be preferable to wait until the specification for refreshing auth > data is finalized? > > For additional background, you can refer to the original DISCUSS > thread [2], but keep in mind that much of it is now outdated. > > Thanks, > Alex > > [1]: https://github.com/apache/polaris/pull/3995 > [2]: https://lists.apache.org/thread.html/xpf60ko823c7mlg5bhnddq3btvdsq5s1 > [Voloridge Logo]<https://www.voloridge.com/> Tommy Bollhofer Senior Data Engineer [cid:dfef5e26-d64e-493e-b55c-c3545ddf18be]<https://voloridge.com/> Voloridge.com<http://voloridge.com/> [cid:db07139f-c750-45db-a035-2b31c5c1f174] [email protected]<mailto:[email protected]> [cid:d694436d-94f2-4a2e-804b-d8b1b948f7b2] 561.231.5770 This email and any attachments are intended only for the intended recipient(s) and may contain information that is privileged and/or confidential. If you are not an intended recipient, or have received this email in error, please notify the sender immediately and permanently delete this email, its attachments, and any copies. Any disclosure, copying, distribution, or reliance on the contents by anyone other than an intended recipient is unauthorized. This email message (including any attachments) is not to be construed as investment advice or the solicitation of an offer to buy or sell interests in any securities. Any information provided in this message must be considered in conjunction with the appropriate disclosure documents. PAST PERFORMANCE IS NOT INDICATIVE OF FUTURE RESULTS.
