Global access control with Apache Ranger#

The integration of Apache Ranger with Starburst Enterprise platform (SEP) enables global access control for all configured catalogs.

Note

Global access control with Apache Ranger requires a valid Starburst Enterprise license.

Policies in Ranger are created with the Ranger user interface and define access and authorization for data sources including Starburst-supported data sources such as relational databases. Each policy combines user and group information with a resource and access rights to the resource. Ranger is configured to your organization’s LDAP system for user and group information. Ranger usage requires the installation of the SEP Ranger plugin. It creates the SEP starburst-enterprise-presto service type, or service definition, in Ranger. This encompasses a SEP-specific set of resources that include catalog, schema, table, column, and more, so access rules for there resources can be configured in Ranger. Specific user interface elements with drop down and auto-completion are available for all resources.

The Ranger SEP plugin is responsible for connecting to Ranger from SEP and using the defined policies for SEP resources. Any user action in SEP, such as submitting a query, is validated against the policies from Ranger and potentially prevented.

For example, a query is parsed and analyzed to determine all involved resources such as schemas and tables. Once a list is created, all policies are analyzed in SEP to determine if the user initiating the query has all necessary access rights. Processing only continues if all rights are granted.

Note

Contrary to the Hive level security, the global access control with Ranger is suitable to define role-based access to catalogs using any connector as well as a number of other system resources.

Using Ranger for role-based access control can be summarized in a few steps:

  • Contact Starburst Support to obtain download access to the Ranger plugin

  • Install Ranger and add the SEP Ranger plugin

  • Configure Ranger for user and group information from LDAP

  • Configure SEP to use Ranger

  • Define policies with the Ranger user interface

  • Enjoy the access control for catalogs, schema, tables and more for all users

Details for all these steps and more are documented in the following sections.

Ranger installation and configuration#

Your first important step is the installation and configuration of Ranger, which can be summarized to the following steps:

  • Install Ranger 2.0.0 or higher

  • Configure Ranger to access your LDAP system for user, group and role information

  • Add SEP Ranger plugin to Ranger

Installation

AWS CloudFoundation deployment

The Starburst support for Amazon CFT-based installation includes installation of Apache Ranger and all relevant configuration. Detailed information is available in the AWS documentation.

K8s deployment

The Starburst support for Kubernetes-based installation includes installation of Apache Ranger and all relevant configuration. Detailed information is available in the Kubernetes documentation.

Connect existing Ranger

Using an existing Ranger 2.0.0 or higher is supported. You just have to make sure that the coordinator has network access to Ranger and LDAP is configured, so that all relevant users, groups and roles are available. As a next step you need install the SEP Ranger plugin.

Manual Ranger installation

If you are running SEP on-premise or some other custom deployment, you need to install Ranger 2.0.0 or higher following the documentation from the Ranger project.

Connect Ranger to LDAP

Ranger needs to access the information about your users, groups and roles in your LDAP system. With the K8s and AWS installation methods, all details are already configured. For existing Ranger usage or manual installation, you need to ensure that Ranger is connected to your LDAP directory provider and a synchronization process is in place. The process varies based on your LDAP system and documented in the Ranger documentation.

SEP Ranger plugin installation#

The SEP Ranger plugin is automatically installed with Ranger when using the AWS CFT and Kubernetes/Helm installations tooling from SEP. For existing Ranger instances or custom Ranger installations, follow the steps below:

  • Download JAR files presto-ranger-plugin.jar and presto-jdbc.jar. Contact Starburst support if you do not have access to these files.

  • Place the JAR files in ${RANGER_HOME}/ews/webapp/WEB-INF/lib directory on the Ranger server.

  • Add the necessary Ranger plugin configuration to connect SEP to Ranger.

  • Restart the Ranger server and the SEP cluster.

  • Create the Ranger configuration properties file for the Ranger plugin configuration.

  • Use the properties file to create the SEP service type in Ranger with the Starburst Ranger CLI:

    starburst-ranger-cli service-definition starburst create --properties=access-control-ranger.properties
    
  • Access the Ranger user interface and confirm that you can find the Starburst Enterprise Presto service type.

  • Add an SEP service type with a service name that matches SEP’s ranger.service-name configuration property by clicking the “plus” icon next to the SEP service type in the Ranger Service Manager.

With the SEP Ranger plugin installed in Ranger, you can create one or multiple services with SEP. This allows you to have separate services for different SEP clusters.

Note

Every upgrade of SEP, requires an upgrade of the SEP Ranger plugin.

Ranger plugin configuration#

With Ranger installed and configured you are now ready to configure Ranger as the activated access control system. Update etc/config.properties and set the path to your Ranger access control configuration file:

access-control.config-files=etc/access-control-ranger.properties

Subsequently configure details in the file:

access-control.name=ranger
ranger.policy-rest-url=http://ranger.example.com:6080
ranger.service-name=presto-production
ranger.presto-plugin-username=<username>
ranger.presto-plugin-password=<password>
ranger.policy-refresh-interval=30s

More details about the supported configuration properties are available in the Ranger overview.

Resource and privilege sets#

All resource and privilege sets, documented in the key concepts section Ranger overview, are available.

Denying access to specific tables and columns#

You may need to restrict access for users to tables or columns for security or other reasons.

Non-Hive catalogs#

The following example shows how to control access for users to tables or columns in non-Hive catalogs, such as a PostgreSQL database exposed by a catalog called``mypostgres``:

  • In the SEP Ranger UI, create an ALLOW policy with SELECT access type and assign it to the users, groups or roles you need.

  • Add a pattern to allow all resources in the the mypostgres catalog:

    • catalog: mypostgres

    • schema: *

    • table: *

    • column: *

  • Create a similar policy in the UI, this time with the DENY type.

  • Add a pattern to deny access to the empl_salary column:

    • catalog: *

    • schema: *

    • table: *

    • column: empl_salary

You can proceed with layering more restrictive access policies for specific columns and tables because Ranger processes DENY policies before ALLOW policies for non-Hive catalogs.

Hive catalogs#

The following example shows how to achieve that for any $path column and any $partitions table exposed by a catalog called myhive:

  • In the Ranger UI, create an ALLOW policy with SELECT access type and assign it to the users, groups or roles you need.

  • Add a pattern to allow all resources in the the myhive catalog:

    • catalog: myhive

    • schema: *

    • table: *

    • column: *

  • Create a similar policy in the UI, this time with the DENY type.

  • Add a pattern to deny access to the $path column:

    • catalog: *

    • schema: *

    • table: *

    • column: $path

  • Create another DENY policy in the UI that restricts access to $partitions tables:

    • catalog: *

    • schema: *

    • table: *$partitions

    • column: *

This method of restricting access works, because Ranger processes DENY policies before ALLOW policies, when evaluating conditions.

Note

The $path column is an artificial column in Hive. It contains information about the location of data file. The table$partitions table contains internal information about the partitioning of the table. All this information should typically not be available to normal users. The above examples shows how you can implement this best practice for catalogs using the Hive connector.

SEP Ranger plugin upgrade#

Typically you automatically get the latest version of the SEP Ranger plugin, when updating and there is no necessary configuration changes you need to apply.

One exception is if you use user impersonation in combination with Ranger. This feature is new with version 345-e, and if you are upgrading to that release you need to perform the following manual upgrade steps.

Before starting this upgrade, you need to gather the following information:

  • the path to your current SEP Ranger plugin, for example ${RANGER_HOME}/ews/webapp/WEB-INF/lib/presto-ranger-plugin-2.0.33.jar

  • your Ranger host information

  • the Ranger plugin download, version 2.0.34+

The changes need to be performed while SEP is not running.

Remove the old plugin:

rm ${RANGER_HOME}/ews/webapp/WEB-INF/lib/presto-ranger-plugin-*.jar

Add the new plugin:

cp presto-ranger-plugin-*.jar ${RANGER_HOME}/ews/webapp/WEB-INF/lib

Start Ranger:

${RANGER_BASE}/start.sh

Recreate the SEP service definition in Ranger with the Starburst Ranger CLI and the properties files as used in the initial installation:

starburst-ranger-cli service-definition starburst override --properties=access-control-ranger.properties

After the service definitions are updated, start SEP.