Security Concern: Vended Credentials — Credential Delegation Violation & Workload Identity Binding

[rajesh-bulleddula]

Environment: Polaris on AWS EKS | Compute Engine (Eg: Spark) on on-prem or AWS | Entra ID as IdP | S3 object storage

---

The Core Security Violation: Vended Credential Delegation

Our organization's security team has flagged a fundamental violation in the vended credentials model as it stands today — one that goes beyond the typical bearer token concern:

The entity that requests the STS token (Polaris) is not the entity that uses it (Spark). Polaris requests vended credentials on its own identity, then hands them to another party, compute engine in this case

This is a credential delegation violation. The standard security principle for STS tokens — and bearer tokens generally — is that the requesting entity is the consuming entity. That assumption is broken here by design

The flow today is:

Spark authenticates via External IDP 
  → calls Polaris REST API with JWT
  → Polaris validates JWT, calls AWS STS AssumeRole
  → Polaris receives STS token
  → Polaris hands STS token back to Spark  
  → Spark uses vended credentials directly against S3
  → S3 validates token is valid — no validation of who is holding it

This is a risk - meaning:

• The credential requestor (Polaris) and the credential consumer (Spark) are different entities
• Any actor who obtains the token — compromised executor, malicious insider, accidental log exposure — can use it against S3 as if they were the original authorized requestor
• AWS CloudTrail will show S3 access under Polaris's assumed role, not under Spark's or the end user's identity
• S3 has no way to enforce that the token is only used by the intended consumer.

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

This is a compliance and audit concern for us, particularly because our compute spans on-premises and multiple clouds, making network perimeter controls (VPC endpoints, IP allowlisting) operationally unscalable and insufficient.

---

What We Are Looking For

We want to understand:

• Whether the credential delegation pattern is a known, accepted limitation of the current architecture
• Whether there are community-endorsed patterns for hardening credential security in multi-cloud environments
• Whether there is roadmap intent to address workload identity binding and credential delegation natively in Polaris

Any input from the maintainers or organizations running Polaris in production at scale would be greatly appreciated. Happy to contribute to a design discussion if there is community interest in tackling this more formally.

#security #compliance #credentials #vended #STS #token

[dimas-b]

@RB-ETArch :

Whether the credential delegation pattern is a known, accepted limitation of the current architecture

This pattern is a feature of the Iceberg REST Catalog API. Polaris supports it for S3 systems by using STS for generating Session Tokens.

Session Tokens are scoped down by the use case (read or write) to the most specific location Polaris can deduce (normally the table's base location).

[dimas-b]

Whether there are community-endorsed patterns for hardening credential security in multi-cloud environments

#3327 enables a rich set of Session tags to be passed down to STS.

#3224 enables passing the API user (authenticated principal) name to STS.

[dimas-b]

Whether there is roadmap intent to address workload identity binding and credential delegation natively in Polaris

Please feel free to propose an enhancement on the dev ML

[dimas-b]

Also: you might be interested in #3170 - that PR did not merge, but if you find this approach valuable, we can certainly re-open that PR and discuss it again (or something similar)

[rajesh-bulleddula]

Thank you @dimas-b 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?

[dimas-b]

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

Certainly. Just configure the Engine to not ask for vended credentials (and optionally disable STS in the Polaris catalog).

Does such a pattern conflict with the current Iceberg REST spec or Polaris’s security model?

I do not think so.

[dimas-b]

Is there any mechanism — where S3 can verify that the entity presenting the token is the same entity that originally authenticated with Polaris?

In short this is related to what #3170 originally proposed (even though it might be a bit simplistic).

For a more complete picture, this probably deserves a dedicated discussion on the dev ML.

[rajesh-bulleddula]

Thank you for the suggestion. I am thinking, when the compute engine fetches its own STS token directly after being authorized by Polaris, not sure if it will receive sub-scoped credentials locked to the specific table file paths as defined in the Iceberg metadata or if it will get broader access to the entire bucket. The per-path scoping that Polaris currently applies during credential vending is important to us and want to make sure that is preserved in this approach.

Will test and report back.

[adnanhemani]

@RB-ETArch - I'm not sure I understand what you mean by this. If the client (e.g. Spark) is the one that is fetching its own STS token since you are not using Polaris' vended credentials, then the client itself is in charge of requesting whatever credentials it wants from a token broker service like STS. In that case, it is your client that must be set up to downscope the credentials as per the request that it is in charge of making; Polaris is no longer involved.

In the case of a compromised Spark node (like you've mentioned in your original message as an attack vector), any downscoping of credentials in this model is practically useless, as user-defined code running on that compromised node can go grab the whole set of permissions per any IAM roles or policies that node is capable of using.

This is exactly why credential vending in Iceberg REST Catalogs (IRC) are powerful and are widely used - the client effectively can only get the set of credentials that the IRC allows it, rather than needing to set each client up with extremely specific IAM roles/policies (which is also quite hard to do in a multi-tenant environment).

[snazy]

The architecture in Polaris is not only common practice; it is considered an Industry-Standard Design Pattern (often called a Token Broker or Security Token Exchange pattern).

In 2026, this is the preferred way to handle client-side access to cloud resources without giving clients permanent credentials or overly broad permissions.

---

How the "Token Broker" Pattern Works

In this flow, the client never talks to the cloud provider (AWS, etc.) to get credentials. Instead, it talks to your Governing Service (the Broker).

1. Authentication: The Client authenticates to your Governing Service (using OAuth2, OIDC, or a custom session).
2. Authorization: The Governing Service checks its own internal logic: "Is User A allowed to see Folder B?"
3. STS Request: If authorized, the Governing Service calls AssumeRole.
4. Dynamic Scoping: Crucially, the service passes a Session Policy (an inline JSON policy) during the AssumeRole call. This "slices" the role’s permissions down to exactly what that specific client needs for that specific session.
5. Credential Yield: The STS response (Access Key, Secret Key, and Session Token) is passed back to the client.

---

Why This is Standard Practice

This approach satisfies several "Zero Trust" security principles:

1. Minimal Blast Radius (Session Policies)

Even if the IAM Role the service uses has S3:FullAccess, the Governing Service can generate a token that only allows S3:GetObject on a single file: my-bucket/users/client-123/*. If that token is stolen, the attacker cannot see any other user's data.

2. Identity Federation & "Identity Hiding"

The Cloud Provider doesn't need to know who your 10,000 end-users are. They only see your Governing Service requesting tokens. This keeps your IAM user list clean and reduces the management overhead of cloud-native identities.

3. Centralized Audit & Governance

By routing credential requests through your own service, you can log business-level context that AWS CloudTrail doesn't see.

• CloudTrail sees: "Service-Role assumed a token with Policy X."
• Your Service logs: "User 'John Doe' requested access to 'Project Alpha' for 'Reason: Debugging'."

4. Short-Lived Ephemeral Secrets

Because these tokens are generated on-the-fly, they typically have a very short TTL (e.g., 15 minutes to 1 hour). Even if a client "leaks" the token (e.g., via a browser log or git commit), the window of opportunity for an attacker is extremely small.

---

Critical Security Guardrails

If you implement this, you must follow these specific implementation rules:

• Policy Hardening: The "Governing Service" must have a Trust Policy that allows it to call sts:AssumeRole. Ensure that only that specific service identity has this power.
• No Downward Escalation: Ensure the Governing Service cannot be tricked into generating a token with more permissions than the service itself has.
• Token Delivery: Ensure the yielded credentials are sent over TLS 1.3 and, if possible, handled only in memory on the client side (avoiding localStorage in browsers where XSS can steal them).

---

Comparison of Patterns

Feature	Direct IAM User	Token Broker (STS)
Credential Type	Permanent (Long-lived)	Temporary (Ephemeral)
Scaling	Poor (Max IAM users limit)	Infinite (Scales with users)
Security	High risk of leakage	Low risk; tokens expire
Granularity	Hard to manage per-user	Dynamic per-request

[rajesh-bulleddula]

I completely agree that STS is industry-standard practice. No disagreement there.

However, we want to clarify the specific concern we are raising, as it is a subtle but important distinction.

The Token Broker pattern assumes:
Client → requests token from Broker → Broker issues token → Client uses token

What happens in Polaris is slightly different:
Polaris → requests token from STS → STS issues token to Polaris → Polaris hands token to Spark → Spark uses token
Polaris is the Requestor. But it is not the Consumer. Spark is.

We are not questioning STS, ephemeral tokens, or dynamic scoping — all of that is solid. 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. The token was issued to Polaris. Spark is the one showing up at S3.

[jornfranke]

"Any actor who obtains the token — compromised executor, malicious insider, accidental log exposure — can use it against S3 as if they were the original authorized requestor"

This is the case with any token you obtain (ie it has nothing to do with how Polaris provides the token). You can have a bucket policy that allows access to the bucket only from trusted private networks (using a condition key based on aws:SourceVpc https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-network-properties with an explicit deny from all other networks).

"AWS CloudTrail will show S3 access under Polaris's assumed role, not under Spark's or the end user's identity"

This is the case with anything that is not AWS. This was a long time a problem in AWS. You may be able to integrate Trusted Identity Propagation for custom applications (https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation-integrations.html) to achieve this.

This may be a feature for Polaris to support.

An alternative would be to simply import all the application logs in your SIEM and check for unusual patterns.

[rajesh-bulleddula]

On the bucket policy workaround — yes, IP address or VPC conditions on the bucket policy could help, but our compute consumers span on-premises, AWS, and Azure. At that scale we would hit bucket policy size limits and the maintenance overhead becomes unmanageable.

On importing logs into SIEM for anomaly detection — yes, this is already part of our plan. However this is inherently reactive. It helps us detect and respond after the fact, but does not prevent unauthorized token use in the first place, which we are trying to address.

Trusted Identity Propagation looks promising as a potential bridge here. Thank you for sharing the link. I will learn more about it and report back here if it can help close the gap.

[adnanhemani]

This is the case with anything that is not AWS. This was a long time a problem in AWS. You may be able to integrate Trusted Identity Propagation for custom applications (https://docs.aws.amazon.com/singlesignon/latest/userguide/trustedidentitypropagation-integrations.html) to achieve this.

As someone who's worked on Trusted Identity Propagation (TIP) in a "past life", it is beyond complicated for non-AWS services (complicated for internal AWS services as well 😅) to integrate with. But I also don't think this "solves" the problem cleanly. Amazon S3 (at least as of when I was last working on it in early 2025) does not understand "identity-enhanced credentials" (which are vended by TIP). The best way around this is to set up Amazon S3 Access Grants and then maintain another set of authZ policies there (S3 Access Grants is also not free btw) - S3 Access Grants will then exchange the "identity-enhanced credentials" for a set of credentials that can talk to S3. Keeping aside the additional roundtrips to AWS you are making on a per-file basis (costing both time and money), we're still not resolving the attack vectors that are listed in the original post.

[adnanhemani]

Noting:

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 satisfies 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 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.