[KYUUBI #7387] Replace serverOnly with audience and immutable on ConfigEntry

[LamiumAmplexicaule]

This implementation is based on the following suggestion.

• [KYUUBI #7387] Replace serverOnly with audience and immutable on ConfigEntry #7451 (comment)

Why are the changes needed?

ConfigEntry.serverOnly conflated two concerns, "don't send to engines" and "users can't override", by stripping entries from the config in getUserDefaults().
This caused kyuubi.server.secret.redaction.pattern to be removed from the session config before ProcBuilder.toString could use it for redacting sensitive values in engine command lines (#7387).

Additionally, conf.getAll sends all configs to every engine regardless of engine type, causing Flink-specific configs to be sent to Spark, Trino configs to Hive, etc.

Splitting these concepts into audience and immutable provides the following benefits:

• Server-side code to always see all config values (fixing redaction — Closes [Bug] kyuubi.server.redaction.regex no longer redacts sensitive values in the "Launching engine:" log line #7387)
• Engine process builders to receive only audience-appropriate configs via getEngineConf

How was this patch tested?

Unit tests.

$ build/mvn test -pl kyuubi-common -am -Dtest=none -DwildcardSuites=org.apache.kyuubi.config,org.apache.kyuubi.session.SessionManagerValidationSuite
$ build/mvn test -pl kyuubi-server -am -Dtest=none -DwildcardSuites=org.apache.kyuubi.engine.dataagent.DataAgentProcessBuilderSuite,org.apache.kyuubi.engine.flink.FlinkProcessBuilderSuite,org.apache.kyuubi.engine.trino.TrinoProcessBuilderSuite,org.apache.kyuubi.engine.jdbc.JdbcYarnModeProcessBuilderSuite,org.apache.kyuubi.engine.jdbc.JdbcProcessBuilderSuite,org.apache.kyuubi.engine.hive.HiveProcessBuilderSuite,org.apache.kyuubi.engine.hive.HiveYarnModeProcessBuilderSuite,org.apache.kyuubi.engine.spark.SparkBatchProcessBuilderSuite,org.apache.kyuubi.engine.spark.SparkProcessBuilderSuite

Was this patch authored or co-authored using generative AI tooling?

Assisted-by: Claude:claude-opus-4-6

[LamiumAmplexicaule]

In the test that checks whether the logs in FlinkProcessBuilder are redacted, I noticed that values in the -D format don’t get redacted, so I removed this filter.

[wangzhigang1999]

I don't think adding an extra serverConf parameter is a good idea. This would result in two configurations that appear identical except for their names, which could cause significant confusion during usage—users might wonder, "Which configuration should I actually use?"

[LamiumAmplexicaule]

Thank you for your comments.

My understanding is that the reason redaction no longer happens after #7054 is that, in

kyuubi/kyuubi-server/src/main/scala/org/apache/kyuubi/session/KyuubiSessionManager.scala

Line 95 in e769f42

val userConf = this.getConf.getUserDefaults(user)

, the sessionConf passed in has the serverOnly configs stripped out.

If we want to obtain kyuubi.server.redaction.regex from ProcessBuilder without passing serverConf, we need to explicitly set it somewhere.
However, it feels wrong to propagate server-side config into the session/engine configs, so I chose the approach of passing serverConf instead.

When passing conf as serverConf, if we strip out everything except serverOnly, we might avoid accidentally referencing serverConf.

[LamiumAmplexicaule]

I am planning to update this PR to pass Option[Regex] instead of serverConf.

[wangzhigang1999]

Thanks for tracking this down!

I'd like to talk about how the fix is done before it lands. Not because the direction is wrong — I'm just not sure that passing the pattern into every ProcBuilder is the best long-term approach. I might be missing something, so feel free to disagree.

What I agree with: redaction is done on the server side, so the pattern has to be read from the server config, not from the config that goes to the engine. That part is correct and necessary.

My concern is the mechanism. conf.get(...) returned None because serverOnly is implemented by removing the entry from the per-session config in getUserDefaults. ProcBuilder runs on the server but holds that stripped config, so redaction quietly turned off. Passing Option[Regex] down fixes redaction, but it only fixes this one symptom:

• It doesn't scale. The next serverOnly config that some server-side code needs while launching an engine will hit the same problem, and we'd add another parameter for it.
• An earlier version of this PR passed serverConf: KyuubiConf instead. I think that's worse: now there are two configs of the same type, told apart only by their variable name — which is exactly the kind of mix-up that caused this bug.

So the real problem is that serverOnly mixes two unrelated things into one "remove": "don't send this to the engine" and "users can't change this". Removing the entry does both, but it also means any server-side code that legitimately needs the value can no longer read it.

There's a related problem with the same cause, which is why I'd rather fix the model than patch it: the launch path does conf.getAll with no per-engine filtering (SparkProcessBuilder), prefixes everything with spark., and ships it. So a Flink tuning key like kyuubi.engine.flink.memory, set in a shared kyuubi-defaults.conf, ends up on the Spark engine's command line as spark.kyuubi.engine.flink.memory=... — harmless noise for tuning keys, but any sensitive value in there rides along too. Both problems are "send everything, then remove a few".

The direction I'd suggest is to split serverOnly into two separate, independent flags, and stop using "remove" to control where a config goes:

• audience — which engines a config is allowed to reach. Instead of removing it from the config, we filter it out when building the engine's startup command. The value is figured out from the key prefix by default (kyuubi.engine.spark.* → Spark, kyuubi.server.* → server-only), and can also be set by hand on the entry when the prefix isn't enough. So most configs need no marking at all, but you can still set it manually when you need to.
• immutable — users can't override it. This is checked when Kyuubi merges the user's config. It's set by hand, on purpose, because "can a user change this?" is a security decision worth deciding per config.

Then serverOnly is just audience(server-only) + immutable, and we can drop it. Two benefits: (1) the value stays in the server config and is fixed, so redaction goes back to a plain conf.get and the Option[Regex] passing here goes away completely; (2) filtering by audience also stops sending one engine's configs to other engines. One model, both problems, no per-config wiring.

flowchart TB
    MASTER["server config (loaded on server, the source of truth)"]
    UO["user config: connection / SET / user-defaults"]
    UO --> IMM{"immutable key?"}
    IMM -->|yes| PIN["user value ignored, server value kept"]
    IMM -->|no| APPLY["user value applied"]
    MASTER --> CONF
    PIN --> CONF
    APPLY --> CONF
    CONF["full config on the server — nothing removed"]
    CONF -->|"conf.get(...)"| READ["server-side reads — redaction sees the real value"]
    CONF --> PROJ{"build config for target"}
    PROJ -->|"engine = Spark"| SPARK["send to Spark: audience is Spark or all-engines"]
    PROJ -->|"engine = Flink"| FLINK["send to Flink: audience is Flink or all-engines"]
    PROJ -->|"logs / REST"| LOG["sent out, masked if sensitive"]

Loading

In short: immutable is checked when a user config comes in, audience is applied when a config goes out, and because nothing is removed from the server config, server-side reads (including redaction) always see the real value — which is exactly what broke here.

Curious to hear your thoughts!

CC @pan3793

[LamiumAmplexicaule]

Thank you for the suggestion.
I think it's a very good idea.
It also reduces the number of items we need to configure in kyuubi.session.conf.restrict.list, which should make it easier to manage.

[LamiumAmplexicaule]

I'm working on implementing the suggestion.

[LamiumAmplexicaule]

Looking at the failing tests, it seems that SERVER_INFO_PROVIDER needs to be mutable.

• kyuubi/integration-tests/kyuubi-hive-it/src/test/scala/org/apache/kyuubi/it/hive/operation/KyuubiOperationHiveEnginePerUserSuite.scala

  Lines 43 to 52 in dfd9b49

  	test("server info provider - server") {
  	withSessionConf(Map(KyuubiConf.SERVER_INFO_PROVIDER.key -> "SERVER"))()() {
  	withSessionHandle { (client, handle) =>
  	val req = new TGetInfoReq()
  	req.setSessionHandle(handle)
  	req.setInfoType(TGetInfoType.CLI_DBMS_NAME)
  	assert(client.GetInfo(req).getInfoValue.getStringValue === "Apache Kyuubi")
  	}
  	}
  	}

Related: #7435

I checked that KyuubiServerInfoProviderSuite passes on this branch.

$ ./build/mvn test -pl kyuubi-server -Dtest=none -DwildcardSuites=org.apache.kyuubi.operation.KyuubiServerInfoProviderSuite