GitHub user RB-ETArch added a comment to the discussion: Security Concern: Vended Credentials — Credential Delegation Violation & Workload Identity Binding
Thank you for pointing to the PR. On sub-scoped credentials — agreed, this limits the blast radius and is valuable. However our concern is less about the breadth of access and more about the delegation pattern itself: the token is requested by Polaris but consumed by Spark. On the session tags PR — this definitely helps for audit trail and CloudTrail visibility. We will be able to trace S3 access back to the authenticated principal and enforce tag presence via bucket policies. That said, two follow-up questions: 1. Is there any mechanism — where S3 can verify that the entity presenting the token is the same entity that originally authenticated with Polaris? Right now S3 only validates that the token is valid, not who is holding it. This is the structural gap we are trying to close. Or 2. Is there a pattern where Polaris authorizes the compute engine, but the engine then fetches its own STS token directly using its own workload identity — rather than Polaris fetching and delegating a pre-issued token? This would make the requestor and consumer the same entity, closing the delegation gap by design. Does such a pattern conflict with the current Iceberg REST spec or Polaris’s security model? GitHub link: https://github.com/apache/polaris/discussions/3972#discussioncomment-16085069 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
