Hi Ranger Devs,
I'm Huafeng Shi, a Committer of Apache Drill. I’m working on authorization
integration between Apache Drill and Apache Ranger, and would like to start a
discussion with the community.
Here is my proposed design:
Apache Drill will expose a generic authorization SPI (contract) for access
control. This SPI is not yet released, I am preparing to submit the
implementation to Drill.
Based on this SPI, we can build a Ranger‑specific authorization plugin for
Drill.
Two possible options for hosting this Ranger‑Drill plugin:
Option A: Contribute the Drill Ranger plugin into Apache Ranger codebase
(target Ranger 3.0).
Option B: Maintain the plugin within Apache Drill repository, once the Drill
authorization SPI is finalized and released.
I would like to clarify several key questions with the Ranger community:
Does the Ranger community accept this overall integration approach: Drill
provides authorization SPI contract, Ranger supplies the plugin implementation
to enforce access control for Drill?
If Ranger community is willing to host this Drill plugin inside Ranger repo for
Ranger 3.0:
I will collaborate with Drill community to finalize and formalize the
authorization SPI in Drill first.
Then I will contribute the Drill‑Ranger plugin code to Ranger.
If the plugin is accepted for Ranger 3.0, are there any requirements for SPI
stability, testing scope, documentation, compatibility we need to follow?
If Ranger prefers not to host Drill plugin inside Ranger repository, is there
any guidance for maintaining it in Drill side as a third‑party Ranger plugin?
Looking forward to your feedback. Thanks a lot.
Best regards,
Huafeng Shi
---- Replied Message ----
FromCharles Givre<[email protected]>Date8/29/2026
05:30To<[email protected]>SubjectRe: [DISCUSS] Package namespace and module
ownership for Drill-Ranger integration (DRILL-8548)
Huafeng, Thanks for this. Have you contacted the Ranger community and asked
this question of them? Are they willing to accept your plugin? It would be
helpful to know this.
For the record, I think this integration will be very valuable to Drill once
complete.
Best,
— Charles
On Aug 27, 2026, at 09:40, huafengshi <[email protected]> wrote:
Dear Drill developers,
First of all, thank you for the detailed review and for raising the
governance‑level issue regarding the Ranger integration PR. I would like to
open a discussion on this matter with the community.
Background The PR currently adds two modules – drill-ranger-plugin and
drill-ranger-service – and all Java code within them resides under the
org.apache.ranger.* package namespace. This potentially raises two issues:
Placing Drill‑specific code under org.apache.ranger.* means that Drill releases
artifacts occupying another ASF project’s namespace. This brings questions such
as:
Who owns, versions, and applies CVE patches to these classes?
Is this acceptable from an ASF policy perspective?
This practice deviates from the established convention in the Apache Ranger
ecosystem. All similar service plugins (e.g., ranger-hive-plugin,
ranger-hbase-plugin, ranger-kafka-plugin, ranger-presto-plugin) are maintained
and released directly by the Ranger PMC, which keeps the package namespace and
release ownership unified within a single project.
Current proposals At this point, we see two high‑level approaches:
Option A: Keep the modules as an independent plugin, rename the package to a
Drill‑owned namespace, and have Drill manage the plugin entirely without being
constrained by Ranger’s release cycle.
Option B: Wait for official feedback from the Ranger community to decide
whether they are willing to accept this plugin as part of their project.
Detailed analysis
Issue 1 (namespace ownership) The solution is straightforward: keep both
modules in Drill but rename the package to
org.apache.drill.exec.security.ranger (or similar), making it clear that this
code belongs to Drill and is maintained by the Drill community.
Issue 2 (alignment with Ranger ecosystem) Moving the drill‑ranger code to
Ranger, where it would be maintained by the Ranger PMC, depends critically on
the attitude of the dev@ranger community. I would like to discuss a few
possible directions with everyone.
(1) What parts of this PR truly belong to Drill?
Sub‑option 1 – Recommended: Drill retains only the generic authorization
contract, and the Ranger‑specific implementation is moved out. Specifically,
the following should stay in the Drill repository:
AccessAuthorizer SPI – the interface contract that any authorization engine can
implement (not biased toward Ranger)
AccessTypes – access type constants
NoOpAccessAuthorizer – the default no‑op implementation, which also
demonstrates the neutrality of the SPI
AccessAuthorizerFactory – the standard ServiceLoader‑based discovery mechanism
(fail‑closed if no provider is found)
ColumnAccessChecker call sites – the integration points within the execution
framework
The parts to be moved out of Drill include: policy engine integration,
RangerAdmin client, auditing, and RangerServiceDrill (the admin‑side service
definition).
With this split, Drill core has zero org.apache.ranger dependencies and can be
released independently.
However, this sub‑option raises several practical concerns that need to be
addressed:
SPI dependency for Ranger: The Ranger plugin would depend on Drill’s
AccessAuthorizer SPI. Drill would only need a one‑time bootstrapping release:
first release a version containing the SPI, then Ranger follows up with the
plugin release. Documentation would clearly state that the actual authorization
capability is provided by the Ranger plugin at installation time. Is this
release ordering feasible?
JDK version mismatch: Ranger currently runs on JDK 8, while Drill uses JDK 17+.
Approach a (recommended): Extract a minimal, independent module drill‑auth‑spi
from java‑exec, compile it with --release 8, and ship it with Drill. This is
exactly what Presto does – presto‑spi is a small, separate artifact published
to Central, and the Ranger Presto shim depends only on that, not on the entire
Presto engine. A side benefit: future implementors for OPA or other
authorization engines would also only need to depend on this small JAR.
Approach b: On the Ranger side, use Maven profiles + toolchains to compile
against Drill’s java‑exec. This is possible but pulls in a much larger
dependency footprint for Ranger, making it less clean than approach (a).
Approach c: Wait for Ranger 3.0 (which will support newer JDK versions).
Summary and next steps I would like the community’s guidance on which direction
we should take. At the same time, if we decide that the service‑plugin part
should move to Ranger, I think we should proactively reach out to the
[email protected] mailing list to understand their willingness to host that
code.
Please share your thoughts. Once we reach consensus, I will update the PR
accordingly.
Thanks,
[huafeng.shi]
