@Rocky Issues: Environment: StarRocks 4.1.6, catalog type Apache Polaris 1. No JWT auto-refresh • Our JWT expires after 1 hour. • Any running query that calls the catalog after that fails. • Request: Let us configure a refresh/renew endpoint in the catalog, so StarRocks refreshes the token automatically and running queries keep working. 1. INSERT fails with JWT auth • SELECT works, but INSERT fails every time. • The insert path creates a new context, and the current user’s identity and JWT are not passed into it. • Expected: The user’s identity and token should carry through to INSERT, the same way they do for reads.

Hello! As Rocky, I've looked into the issues you're experiencing with StarRocks 4.1.6 and the Apache Polaris (Iceberg REST) catalog. 1. No JWT Auto-Refresh (Identity Passthrough) The behavior you're seeing is a known limitation of the Identity Passthrough (

"iceberg.catalog.security" = "jwt"

) mechanism introduced in recent versions (v4.0+). * Current Behavior: When using

security = jwt

, StarRocks passes the specific JWT used by the user to log in to StarRocks directly to the Polaris catalog. Since this token is owned by the client session, StarRocks does not currently have a mechanism to "refresh" it using a refresh token or a secondary endpoint; it simply forwards what it was given. If the token expires (e.g., after 1 hour), the Polaris catalog will return a

401 Unauthorized

for any subsequent metadata or data requests. * Status: There is currently no configuration property in StarRocks to define a refresh endpoint for passthrough tokens. A similar issue has been tracked regarding recovery from failed token refreshes in

oauth2

mode (see Issue #76438). * Workaround: Clients must re-authenticate and establish a new session once the token expires. 2. INSERT Fails (Identity Propagation in Write Path) The failure of

INSERT

while

SELECT

works suggests a gap in how the user's security context is propagated during write operations. * Technical Root: In StarRocks, while the Frontend (FE) successfully uses the passthrough JWT for planning and metadata lookups (which is why

SELECT

works), the write path (especially the final

commit

call to the Iceberg REST catalog) often executes in a different context. If the BE or the FE's internal committer does not carry over the

UserIdentity

and the associated JWT to the REST client used for the write, the catalog rejects the operation. * Expected Fix: This is recognized as a bug/omission in the identity propagation logic for the Iceberg REST connector's write path. The identity must be explicitly attached to the

SecurityContext

of the background threads or RPCs responsible for the commit. Recommendations 1. Reporting: Since you are on version 4.1.6 (released late 2026), these specific issues regarding Polaris identity propagation are best addressed by the CelerData support team or by opening a specific issue on the StarRocks GitHub detailing the

INSERT

failure stack trace. 2. Configuration Check: Ensure your catalog is not accidentally falling back to a default credential. Double-check if adding

"iceberg.catalog.rest.authorization-header-passthrough" = "true"

(if available in your specific build) helps, though this is usually the default for

security = jwt

. 3. Community: If you're using the open-source version, I recommend tagging the maintainers in the

#external-catalog

or

#iceberg

channels in the StarRocks Community Slack to see if a hotfix for identity propagation in the write path is available for the 4.1.x branch. Would you like me to look up any specific FE configuration parameters related to session timeout extensions? References • administration/user_privs/authentication/jwt_authentication.md • data_source/catalog/iceberg/iceberg_rest_security.md • administration/user_privs/authentication/security_integration.md