GitHub user snazy added a comment to the discussion: Security Concern: Vended Credentials — Credential Delegation Violation & Workload Identity Binding
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 | GitHub link: https://github.com/apache/polaris/discussions/3972#discussioncomment-16086305 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
