[
https://issues.apache.org/jira/browse/SPARK-59324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
L. C. Hsieh resolved SPARK-59324.
---------------------------------
Fix Version/s: connect-gateway-0.1.0
Resolution: Fixed
Issue resolved by pull request 22
[https://github.com/apache/spark-connect-gateway/pull/22]
> Run the trust-boundary end-to-end walkthrough in CI
> ---------------------------------------------------
>
> Key: SPARK-59324
> URL: https://issues.apache.org/jira/browse/SPARK-59324
> 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 deploy/examples/e2e-trust-boundary walkthrough is what verifies the
> gateway-to-backend trust boundary: the backend enforces
> spark.connect.authenticate.token, the gateway presents it, and clients must
> not be
> able to read it back. None of that was covered by CI. The in-process tests
> cover the
> outbound-credential plumbing, but nothing verified the deployed arrangement
> or the
> Config-response withholding against a real Spark backend.
> This adds an e2e-trust-boundary job to the E2E workflow, on its own kind
> cluster,
> running the walkthrough's four assertions:
> (1) A direct connection to the backend, bypassing the gateway, is refused with
> UNAUTHENTICATED "No authentication token provided". This runs before the
> gateway is
> installed, so nothing could be presenting a token.
> (2) The same client succeeds through the gateway, whose startup log confirms
> "outbound backend authentication enabled".
> (3) Negative control: with backendToken.enabled=false, that same client
> through that
> same gateway is refused again with the identical error. Without this, (2)
> would prove
> nothing; it is what shows the token is the discriminator rather than the
> network path
> or some other setting.
> (4) A client asking the Config RPC for spark.connect.authenticate.token sees
> it
> unset, and the gateway records a config.redacted audit event naming the
> withheld key.
> Assertion (4) is why the token layer holds at all: Spark's Config RPC will
> otherwise
> hand back any config key the server holds, which would let any client read the
> credential and then dial the backend directly.
> The walkthrough's NetworkPolicy half is deliberately out of scope: kind's
> default CNI
> does not enforce NetworkPolicy, which is itself why the token layer matters,
> since it
> does not depend on the CNI.
> Verified by running all four assertions locally first: direct connection
> refused,
> through-gateway query returned 10 rows, tokenless gateway refused with the
> identical
> error, and the token read back as unset with one config.redacted audit event
> naming
> spark.connect.authenticate.token.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
