Hi Tommy, Thanks for chiming in! Your reply got disconnected from the thread though, so here is the link to my first message just in case:
https://lists.apache.org/thread.html/vk5zj7qtrztl36c9c1qt6d09lryjltdk The details you provide are very valuable: since FlashBlade doesn't support AssumeRole, remote signing becomes indeed a good alternative. And since you can live for now without auth-credentials refresh, it seems to me we have enough evidence that we should move forward and provide a first, experimental implementation of remote signing. I will start preparing a revisited PR, built on top of the old one. Thanks, Alex On Thu, Oct 22, 2026 at 7:06 PM Tommy Bollhofer via dev < [email protected]> wrote: > 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 > > > > [image: Voloridge Logo] <https://www.voloridge.com/> > > Tommy Bollhofer > Senior Data Engineer > <https://voloridge.com/> > > Voloridge.com <http://voloridge.com/> > [email protected] > 561.231.5770 <(561)%20231-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. > >
