[KYUUBI #7671][AUTHZ] Cover all injected authz rules in the excludedRules check - #7672
[KYUUBI #7671][AUTHZ] Cover all injected authz rules in the excludedRules check#7672alexandrefimov wants to merge 1 commit into
Conversation
…ludedRules check AuthzConfigurationChecker rejects a spark.sql.optimizer.excludedRules value that names org.apache.kyuubi.plugin.spark.authz.ranger, which was the whole extension when the check was written. Most rules live under org.apache.kyuubi.plugin.spark.authz.rule now, so a rule added there is outside the denylist. Match the extension's own package instead. Of the four optimizer rules the extension injects, the three in …authz.rule only strip markers after the check has run, so excluding one of them breaks the query rather than lifting a check - this is future-proofing rather than a live bypass, and it rejects configurations that are accepted today.
|
The one red check, Could someone re-run that job? The |
There was a problem hiding this comment.
Thanks, LGTM
If we accept this PR, it may mean that we can no longer disable the data masking and row filter rules independently. However, I think a better way to support that use case would be to provide an additional RangerSparkExtension without the data masking and row filter rules, as discussed here: #7082 (comment).
So I'm fine with the current change.
2 participants
Why are the changes needed?
Closes #7671, the follow-up @wForget asked for while reviewing #7637.
AuthzConfigurationCheckermatchesorg.apache.kyuubi.plugin.spark.authz.rangerin the effectivespark.sql.optimizer.excludedRules, which was the whole extension when the check was written. Most rules live underorg.apache.kyuubi.plugin.spark.authz.rulenow, so a rule added there is outside the denylist. This matches the extension's own package instead.It is future-proofing rather than a fix for a live bypass, and worth saying why.
spark.sql.optimizer.excludedRulesfilters optimizer batches only and Spark has no analyzer counterpart, so the resolution rules that apply masking and row filtering cannot be excluded at all. Of the four optimizer rulesRangerSparkExtensioninjects,RuleAuthorizationis in…authz.rangerand already covered; the other three —RuleEliminateMarker,RuleEliminatePermanentViewMarker,RuleEliminateTypeOf— only strip markers after the check has run, and excluding one of them breaks the query instead of lifting a check.The change does reject configurations that are accepted today, which is why it is separate from #7637 rather than part of it.
How was this patch tested?
A new case in
AuthzConfigurationCheckerSuitecovers the three…authz.rulerules by theirruleName, through both paths the checker guards: the value in effect, and theSETsyntax.30 tests green across
AuthzConfigurationCheckerSuite,DataMaskingForInMemoryParquetSuiteand the row filtering suite. With the constant reverted to the ranger package the new case fails, so it tests the change rather than the code around it.Was this patch authored or co-authored using generative AI tooling?
Assisted-by: Claude Opus 5