Repository navigation
Conversation
Add kyuubi.internal.security.crypto.compatibilityMode to support rolling upgrades from Kyuubi 1.11.1 or earlier. STRICT issues and accepts only random-IV-prefixed tokens, READ_COMPATIBLE accepts both formats while issuing current tokens, and MIGRATE issues legacy zero-IV tokens while accepting both. Document the phased MIGRATE to READ_COMPATIBLE to STRICT rollout and cover legacy token generation, secret normalization, and random-IV behavior in tests.
github-actions
Bot
added
kind:documentation
wangzhigang1999
left a comment
wangzhigang1999
left a comment
There was a problem hiding this comment.
Thanks @aajisaka, LGTM. I tested a57caf2f8 on a Kubernetes test cluster with Spark in local mode, using the PR server to launch the unmodified 1.11.1 engine JAR.
Keeping the same engine running and restarting only the server, I confirmed:
STRICT: authentication failed.MIGRATE: SQL succeeded.READ_COMPATIBLE: authentication failed.- Switching back to
MIGRATE: SQL succeeded again.
I also checked the loaded classes to confirm the engine used the 1.11.1 InternalSecurityAccessor. The engine registered under the namespace supplied by the new server without any ZooKeeper changes. This confirms that legacy token issuance is needed for the scenario in #7745; decrypt-time fallback alone is insufficient.
During validation, I noticed an existing REST issue: invalid internal tokens return HTTP 500 because authToken throws KyuubiSQLException, while AuthenticationFilter catches only AuthenticationException. I reproduced this on 1.11.1 too, so I think we should handle it in a separate follow-up rather than block this PR.
…lity mode Move the compatibility mode under the legacy namespace as kyuubi.internal.security.legacy.crypto.compatMode, since the mode is temporary and will be removed. Use 1.11.x rather than 1.11.1 in the rolling upgrade wording, as 1.12.0 already issues random-IV tokens and thus behaves like STRICT, and state that replacing engines is only needed when an engine resource such as kyuubi.session.engine.spark.main.resource is set explicitly, since otherwise a replacement server picks up the engine jars shipped in its KYUUBI_HOME.
This branch has not been deployed
3 participants
Why are the changes needed?
To fix #7745
Add
kyuubi.internal.security.crypto.compatibilityModeto support rolling upgrades from Kyuubi 1.11.1 or earlier.STRICT(default, same as 1.12.0 behavior) issues and accepts only random-IV-prefixed tokensREAD_COMPATIBLEaccepts both formats while issuing current tokensMIGRATEissues legacy zero-IV tokens while accepting both.Document the phased
MIGRATEtoREAD_COMPATIBLEtoSTRICTrollout and cover legacy token generation, secret normalization, and random-IV behavior in tests.How was this patch tested?
Added unit tests.
Was this patch assisted by generative AI tooling?
Assisted-by: OpenCode (MiMo-V2.6-Pro)