[
https://issues.apache.org/jira/browse/SPARK-59360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
L. C. Hsieh resolved SPARK-59360.
---------------------------------
Fix Version/s: connect-gateway-0.1.0
Resolution: Fixed
Issue resolved by pull request 23
[https://github.com/apache/spark-connect-gateway/pull/23]
> Run the multi-tenant routing end-to-end walkthrough in CI
> ---------------------------------------------------------
>
> Key: SPARK-59360
> URL: https://issues.apache.org/jira/browse/SPARK-59360
> Project: Spark
> Issue Type: Sub-task
> Components: Connect
> Affects Versions: connect-gateway-0.1.0
> Reporter: L. C. Hsieh
> Assignee: L. C. Hsieh
> Priority: Major
> Labels: pull-request-available
> Fix For: connect-gateway-0.1.0
>
>
> The e2e workflow covers baseline routing, JWT identity, and the backend
> trust boundary, but nothing in CI exercises per-tenant backend pools.
> The multi-tenant walkthrough under deploy/examples/e2e-multitenant has
> never run automatically, so the chart's tenantPools.overrides templating
> and the gateway's pool-isolation behaviour are only verified by hand.
> This adds an e2e-multitenant job that stands up two independent Spark
> Connect deployments, one per tenant, and asserts:
> (1) The chart renders both tenant pool overrides plus the strict
> onUnknownTenant=reject policy, and the gateway starts one Kubernetes
> Endpoints watcher per override pool with no default pool at all.
> (2) Two clients with JWTs claiming different tenants both succeed, and
> the session.create audit events show each tenant reached only its own
> backend Endpoint. This is the isolation assertion: the backend IPs are
> captured from the two Services beforehand and compared exactly, so a
> routing regression that sent both tenants to one pool would fail.
> (3) A JWT claiming a tenant with no configured pool is rejected with
> PermissionDenied, while a JWT carrying no tenant claim is rejected with
> Unauthenticated. The two rejects must stay distinct: one identified
> itself and was refused, the other never identified a tenant.
> (4) Both rejects are observable -- the unknown tenant as an rpc.error
> audit event, the missing claim as an auth.failure with
> reason=missing_tenant plus its metric -- and only the two successful
> sessions bound a backend.
> Verified locally against a kind cluster before wiring it up: each tenant
> stayed pinned to its own backend across repeated sessions, and both
> reject paths returned the documented status codes and messages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
