GitHub user adnanhemani closed the discussion with a comment: Security Concern: Vended Credentials — Credential Delegation Violation & Workload Identity Binding
From: > The concern is specifically that S3 has no way to verify that the entity > presenting the token is the same entity that requested it from STS. and > Threat vectors our security team has identified: A compromised Spark executor node exfiltrates the token and uses it outside the cluster A malicious insider on the compute cluster copies the token and accesses S3 independently The token is accidentally logged and replayed within its TTL window A man-in-the-middle intercepts the token in transit from Polaris to Spark I, personally, don't think there is any model which satisfied both the attack vector and your concerns without placing some level of responsibility on the client side of things. @jornfranke's response is bluntly correct - I don't think your issues with token-level security have anything to do with Polaris or even IRC credential vending. Any set of credentials can be exfiltrated and used somewhere else technically, neither Polaris nor IRCs in general claim to solve this issue on the client-side. I'd recommend @dimas-b's [comment](https://github.com/apache/polaris/discussions/3972#discussioncomment-16084054) for passing user information into the vended credential if what you're looking for is reactive reporting of which user had originally requested this token (and should, barring some security loophole, be the user using this credential). If you're looking for a solution to proactively have S3 allow/deny requests based on a credential *and* some information about the client, then I believe Polaris is not the right repo to ask these questions. GitHub link: https://github.com/apache/polaris/discussions/3972#discussioncomment-16204522 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
