Hi all,
I’d like to discuss whether Ranger Hive authorizer should expose a small
extension point for creating its RangerPluginConfig programmatically.
Today RangerHiveAuthorizer internally creates a singleton RangerHivePlugin,
and RangerHivePlugin uses the default XML-loading RangerPluginConfig path.
This works well for traditional deployments where HiveServer2 has
ranger-hive-security.xml, ranger-hive-audit.xml, and related files on the
classpath.
This is difficult in some environments where the Ranger connection details
are already available in code. For example, an embedding or federated query
engine may create authorizers dynamically and may not have a good way to
place per-connection Ranger XML files on the classpath. In those cases,
passing the same settings as Properties would be simpler.
Would the community be open to a minimal, backward-compatible hook in
RangerHiveAuthorizer, for example:
protected RangerPluginConfig createPluginConfig(
String appType,
HiveConf hiveConf,
HiveAuthenticationProvider authenticator,
HiveAuthzSessionContext sessionContext)
The default implementation would preserve the current behavior by returning
the existing XML-loading config:
new RangerPluginConfig("hive", null, appType, null, null, null)
RangerHivePlugin would also get a constructor accepting RangerPluginConfig
and pass it to RangerBasePlugin.
This would let custom HiveAuthorizerFactory/RangerHiveAuthorizer subclasses
provide Properties-based configuration without copying RangerHiveAuthorizer
or using reflection. Existing XML-based deployments would be unchanged.
This proposal does not attempt to solve multiple Hive plugins in the same
classloader/JVM; the current static singleton behavior would remain. It
only makes bootstrap configuration injectable for environments that already
control authorizer/plugin lifecycle externally.
Thoughts?
Best regards,
Tamas
