Yes. You can start with a service-definition containing only currently supported resources and access-types in Apache Drill authorization model. Service-definitions can later be updated as the authorization model evolves.
Madhan On 8/31/26, 5:41 PM, "huafengshi" <[email protected] <mailto:[email protected]>> wrote: Hi Madhan, Thank you for your reply and the clear guidance from the Ranger community. I have one point to confirm with you: In phase‑1 development, Drill only supports basic access types including CREATE, SELECT and DROP. Other access types such as INSERT, row‑level filtering and data masking features are not yet implemented. Would it be acceptable if I submit this initial, incomplete service‑definition to the Apache Ranger repository first? After row‑level filtering and masking are implemented later, I will submit follow‑up PRs to extend and update this service‑definition. ---- Replied Message ---- FromMadhan Neethiraj<[email protected] <mailto:[email protected]>>Date8/30/2026 23:[email protected] <mailto:[email protected]><[email protected] <mailto:[email protected]>>[email protected] <mailto:[email protected]><[email protected] <mailto:[email protected]>>SubjectRe: Subject: [DISCUSS] Integrate Apache Drill with Apache Ranger via authorization SPI Hi Huafeng Shi, Thank you for reaching out to Ranger community and the providing appropriate details. Here is the preferred integration approach from Ranger community: 1. Service-definition, describing the resources and access-types, is committed in Apache Ranger git repo, so that it is automatically registered during Ranger admin server bootstrap. 2. Plugin implementation itself remains in Apache Drill git repo With this approach, Apache Drill community will avoid dependency on Apache Ranger releases for any enhancements in authorizer implementation - for example changes in authorization SPI or fixes. This will also help avoid having to deal with JDK version differences across the projects. Here are few references for this integration model: - Trino: https://github.com/trinodb/trino/tree/master/plugin/trino-ranger <https://github.com/trinodb/trino/tree/master/plugin/trino-ranger> - Polaris: https://github.com/apache/polaris/tree/main/extensions/auth/ranger <https://github.com/apache/polaris/tree/main/extensions/auth/ranger> Blog on "Integrating Applications with Apache Ranger" can be a useful reference as you look into integration: https://ranger.apache.org/blogs/integrating_applications.html <https://ranger.apache.org/blogs/integrating_applications.html>. Thanks, Madhan On 8/30/26, 4:55 AM, "huafengshi" <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote: 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] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>>Date8/29/2026 05:30To<[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[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] <mailto:[email protected]> <mailto:[email protected] <mailto:[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] <mailto:[email protected]> <mailto:[email protected] <mailto:[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]
