Service Definition in Apache Ranger¶

Apache Ranger provides a flexible and extensible framework for defining and enforcing access control policies across a variety of data services. At the core of this capability is the Service Definition, which acts as a blueprint for how Ranger understands and manages resources for a particular service type.

What is a Service Definition?¶

A Service Definition describes:

• The types of resources a service exposes (e.g., databases, tables, columns)
• The types of access permissions that can be applied (e.g., SELECT, UPDATE)
• The hierarchical relationship between resources
• The matchers used to define how resources are evaluated (e.g., exact, wildcard, recursive)

Service definitions are used by Ranger to generate UI forms, interpret policy logic, and enforce permissions.

Built-in Service Types¶

Privacera supports most of the major data platforms available across leading cloud providers. These service definitions are available by default. Here are some examples:

Refer to the list of connectors for the full list of supported services and their service definitions.

Custom service definitions can also be added for proprietary or non-standard systems. Please contact Privacera Representative for more information.

Resource Hierarchy¶

In Apache Ranger and Privacera, Resource Hierarchy refers to the ordered structure of data entities within a service. It defines how data is organized—from broad containers like databases or buckets to specific elements like columns or objects.

This hierarchy determines:

• How policies are evaluated (from most specific to most general)
• Which permissions are inherited across levels
• How policy scope is defined whether broadly (e.g., entire database) or narrowly (e.g., a single column)

The hierarchy varies by service. For example:

• Snowflake: Database → Schema → Table → Column
• S3: Bucket → Path → Object
• Kafka: Topic → Consumer Group

Resource Hierarchy Example (Snowflake)¶

In Snowflake, resources are structured in a multi-level hierarchy:

Database → Schema → Table → Column

This hierarchy allows policies to be written and enforced at varying levels of granularity. Each level represents a progressively more specific scope of access control.

Why Resource Hierarchy Matters¶

Resource hierarchy enables:

• Simplified policy management: Define broad policies at higher levels (e.g., database) and override them at lower levels if needed.
• Inheritance of permissions: Policies defined at a parent level apply to all child resources unless explicitly overridden.
• Fine-grained control: Column-level masking or filtering policies allow for privacy and compliance enforcement on sensitive fields.

How Policies Are Interpreted¶

When a user makes a request (e.g., SELECT from sales_db.orders.customer_email), the policy engine evaluates permissions in the following order:

1. Exact match: If there is a policy explicitly defined for that column or table, it is applied.

2. Inherited match: If there is no direct policy, the engine checks policies defined at the parent levels:

   • Table
   • Schema
   • Database

Policy Examples¶

Best Practices¶

• Define broad access at the database or schema level for ease of administration.
• Use table-level policies to scope team-level access (e.g., marketing team on leads table).
• Apply column-level masking or row-level filters to protect sensitive data (e.g., PII or financial info).
• Use tag-based policies in conjunction with resource-level policies for more dynamic control.

Access Types¶

Access types define the actions that can be performed on resources. Each service definition includes a set of access types that are relevant to that service. Here are some examples:

Where is the Service Definition Used?¶

• Policy Admin UI: The UI for managing policies is generated from the service definition.
• Plugins: Ranger plugins use the service definition to understand the context and apply access checks.

Comments