We've done that for a while for all s3a access in cloudera's products using kerberos principals as the identities. S3A code has all the hooks underneath (delegation token plugin point mainly), though the AWS SDK causes some problems as it occasionally likes to do its own thing. Let's just say "it's a regression point".
1. the service needs to cache a lot 2. to assist this, you can strip out some of the headers (date? range? I forget) so there's no need to recalculate signatures when these change steve On Thu, 8 Jan 2026 at 20:15, Daniel Weeks <[email protected]> wrote: > Alex, > > Customization was included in the reference implementation, but I don't > think it's clearly reflected in the spec, so I don't believe it would be > fully spec compliant currently. > > I believe most implementations of the signer are using request > identity/authorization information to sign for specific paths, but without > having the ability to associate the path with the owning resource, it can > be difficult to check the authorization. > > We probably need to evolve the spec (either by explicitly calling out that > paths can be dynamically created by the server and passed in the load table > bundle) or by explicitly defining a well defined resource path with the > necessary parameters if that information is necessary. > > I think Christian may have more context on an approach to addressing the > signer behavior, so I would love to have his input here. > > -Dan > > > > On Thu, Jan 8, 2026 at 10:24 AM Alexandre Dutra <[email protected]> wrote: > >> Hi all, >> >> We are currently integrating S3 remote signing into Apache Polaris [1]. >> >> A key topic of discussion [2] is the signer endpoint, which is defined >> as "v1/aws/s3/sign" in s3-signer-open-api.yaml [3]. >> >> The main concern with the default value is its rigidity and lack of >> path parameters for important elements like namespace, table, and >> potentially a general-purpose prefix. >> >> This leads to my two questions regarding this endpoint: >> >> 1. Customization: is it spec-compliant to customize this endpoint's >> path? My understanding, based on the commit introducing the feature >> [4], is that it is. >> >> 2. Scope: should it be treated as a top-level endpoint (similar to the >> config endpoint), or is it better considered an internal >> implementation detail of the signer client? (This is important to >> Polaris because top-level endpoints require higher evolution >> guarantees.) >> >> I would love to hear from the community, especially those involved in >> the S3 remote signing implementation! >> >> Thanks, >> Alex >> >> [1]: https://github.com/apache/polaris/pull/2280 >> [2]: https://lists.apache.org/thread/8qgv9ccyhhybokmckvf20r8hl1ng74xs >> [3]: >> https://github.com/apache/iceberg/blob/main/aws/src/main/resources/s3-signer-open-api.yaml#L61 >> [4]: >> https://github.com/apache/iceberg/commit/80766723588985c4592ffb336a76eabc046d01a9 >> >
