Apache Ranger: the policy store is not in the request path

The plugin downloads policies and decides on the spot

The enforcement mechanism is the whole design, and it is stated in three sentences. Policies are managed in one place, Ranger Admin, through its web interface or its REST API. They are enforced by Ranger plugins that run inside the protected services. And those plugins also record an audit trail of access decisions. Then there is the detail that makes it viable: to protect a service you set up its plugin, the plugin downloads the service's policies from Ranger Admin, authorises each request locally, and sends audit events to the audit store. So the request path never calls Ranger Admin. A query against Hive reaches HiveServer2, the plugin there holds a local copy of the policies, decides, and permits or denies without a network round trip to a central service. That is a deliberate architecture and it buys two things. Latency is unaffected, and Ranger being unavailable does not stop your queries. It also creates the trade you have to understand: policy freshness is bounded by how often the plugin refreshes its copy, so a change made in the web interface is not instantaneous across the estate, and the repository does not state the interval. The audit trail has the opposite property, since the plugin writes the decision events itself, which means the audit store is a separate dependency with its own availability characteristics, and in the quick start that store is Solr.

The table has two columns, and the second one decides your upgrade path

The integration table lists twenty-two services, and it is worth reading the columns rather than the rows. The first column says where the plugin runs, which is the information you need for deployment. The second says who ships it, and that column splits the list in two. Most entries say the plugin ships with Apache Ranger: Atlas, Elasticsearch, Kafka, KMS, Kylin, Sqoop, Ozone, Solr, YARN, Knox, HBase, Hive, HDFS, and Ranger KMS among them. A smaller set ships with the service itself: Trino, Impala, Kudu, Schema Registry, and NiFi, and in the case of NiFi both the framework and its registry. The practical consequence is bigger than it looks. If the plugin ships with Ranger, your integration version is pinned to the Ranger release, and the archive name tells you exactly what to deploy, since plugins that ship with Ranger are released as ranger-<version>-<service>-plugin.tar.gz archives and a source build writes the same archives to the target directory. If the plugin ships with the service, then Ranger's release cadence is irrelevant to you; the service's own version decides which plugin you get and how you enable it in that service's configuration. Planning an upgrade of Trino and planning an upgrade of Hive are therefore different projects, and the table is the document that tells you which kind of project you have. The KMS plugin is called out as the exception that is part of this repository rather than built separately.

Three integration paths, and the third one is for code you own

The last paragraph of the plugin section covers the case the table cannot, which is an application that is not on the list. Such applications can authorise requests with the Ranger authorisation API, and there are two ways to use it. One evaluates policies in process, inside the application, which is the same local decision the plugins make and has the same latency profile and the same staleness property. The other sends each request to the policy decision point server, and the README notes this is available from the 2.9 release onwards. That is a real architectural choice rather than a convenience, because the remote path puts a service call in front of every authorisation decision. You get policy updates without a restart and without a local cache to reason about, and you pay a network hop and a new availability dependency on a service that must be sized for your request rate. So the three paths are: in-service plugin, in-process evaluation, or remote evaluation, and they trade freshness against latency in the same way. This is also the boundary of the product. Ranger enforces inside services it has plugins for, or inside applications you instrument yourself, and it does not mediate access to a system with no integration point at all. If your estate is one service with one permission model, this adds a central control plane and a plugin without removing any work.

Row filters, column masks, and three ways to classify what a policy applies to

The sentence that distinguishes Ranger from a table-level grant checker is short and worth quoting in full, because it names three things. Policies can be based on resources, tags or attributes, and they can filter rows and mask columns. Row filtering and column masking are the two capabilities that turn an access rule into a data rule, and they are the reason a data team would want this rather than a grant list. A resource-based policy is the familiar case, where the rule names a table or a column. Tags and attributes are the other two, and they matter because they let a policy follow the data rather than its location: if your catalogue attaches a tag to a table, a policy keyed on that tag keeps working when the table moves, is renamed, or is created by a pipeline nobody reviewed. That is the coupling with Apache Atlas, which appears in the table as a service whose plugin runs in the Atlas server, and the two projects are designed to be complementary, Atlas holding the metadata and Ranger enforcing against it. The attribute case is the one deployments most often skip, because role-based rules are the conventional starting point and attributes require the data to carry its own classification. If you are evaluating Ranger for a compliance requirement, the question to ask is not whether role-based rules are possible, since they are, but whether anyone will own the tag or attribute assignment that makes the finer rules expressible.

Three containers and a password that is printed in the README

The quick start is unusually complete, and the first thing it does is hand you a credential. Released Ranger Admin images are published on a container registry, and the stack is three images: the admin service, a database image which is PostgreSQL, and an audit store image which is Solr. The registry page carries the commands to start all three, and then you open a local port and log in with the username admin and a password spelled out in the README. The project is explicit about what this is for. The images are for evaluation and development, and they use well-known default passwords. That sentence is worth crediting, because a password printed in a README is exactly the thing that ends up in a production deployment, and the alternative is a quick start that fails on first login for reasons the reader does not understand. Still, treat the warning as a hard boundary. Anything you build from this stack is a development environment, and the step from it to a real deployment is where the database, the audit store, the credentials and the network exposure all have to be reconsidered. The audit store deserves a specific thought, because it is the component that holds your access history, and it is the one people forget to size. An audit store that fills up, or that nobody backs up, is how a compliance capability quietly stops being one.

One archive per service, plugin and tool, and CI that starts the containers

The build section tells you what the project considers a unit of deployment, which is unusually granular. After a build you get a ranger-<version>-<component>.tar.gz archive for each service, plugin and tool, written to the target directory, with the admin archive given as the example. So the release is not one tarball; it is a set, and the packaging is per plugin. The build itself is Maven with two documented speeds:

mvn clean install                # full build: unit tests and code checks
mvn clean package -DskipTests    # faster: skips unit tests and code checks

and the requirements are listed precisely, including a JDK version, a minimum Maven version, Python 3 only for the client tests and therefore skippable, and a container runtime only if you intend to build or run in containers. There is also a path with no local toolchain at all, a build container in the development support directory that writes the archives to its own dist directory, and an IntelliJ code style scheme checked into the repository, which is a small courtesy that tells you the project expects IDE use. The CI description in the contributing section is the part that tells you how much is actually verified. It runs mvn clean verify on the same JDK, and the checks listed are unit tests, Checkstyle, PMD, SpotBugs and the licence audit, and it also checks that the Docker containers start. That last item is the meaningful one for a product that ships as a set of containers: something in the pipeline proves the images boot.

A threat model file, a numbered pull request, and two naming schemes

Three process details, then one inconsistency. The project ships a threat model document at the repository root, which is rare and entirely appropriate for a product whose job is deciding who may read what. The contribution path is stricter than most: find or file an issue in the project tracker, discuss anything large on the development list first, then open a pull request against master with a title in the form RANGER-XXXX followed by the subject and a filled template, and keep continuous integration green. Security problems go to a private address, explicitly not to the tracker, the repository or the mailing lists, and the reference to a separate security document confirms there is a process behind that. The inconsistency is in the module names. The plugin table and the build both imply one naming scheme, and most of the tree follows a plugin- prefix, so plugin-kafka, plugin-hive's sibling plugin-solr, plugin-trino and the rest. Four directories break it and use an agent suffix instead, for HBase, HDFS, Hive and Knox. The distinction is not explained anywhere in the README, which means a contributor looking for the directory to change a Hive rule will find plugin-nifi or plugin-atlas first and have to work out that hive-agent is the one they want. There is also a family of modules with an agents prefix, alongside a coding-agent configuration directory and an agent instruction file, in a project whose stated scope covers data and AI platforms, which suggests the agent-facing surface is being built out rather than merely bolted on.

Editorial conclusion

Adopt Ranger if you have more than one service that needs the same access rules enforced and audited in one place, because the plugin model means no request waits on Ranger Admin, and the row filter and column mask capabilities are what make a policy more than a table-level grant. Do not adopt it as a single-service permission system, since the whole value is the central store and a per-service plugin that has to be installed and kept current. Three things to check before you install anything. Find out whether the service you care about ships its own plugin, because for Trino, Impala, Kudu, Schema Registry and NiFi the service's release cadence governs the integration rather than Ranger's. Decide between the two authorisation paths for your own applications, evaluating policies in process or calling the policy decision point, where the remote option exists from the 2.9 release onwards. And treat the Docker quick start as evaluation only, as the README says, because it logs in with a published default password that will otherwise reach a deployment.

Frequently asked questions

Official sources

1. apache/ranger on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README