Ranger access control#

The Ranger access control plugin supports use of Apache Ranger policies to authorize data access in Trino on catalogs, schemas, tables, and columns. The plugin also supports column-masking, row-filtering and audit logging.

Requirements#

Access to a Apache Ranger deployment with the desired authorization policies.
Access to an audit store using Solr, HDFS, Log4J, Elasticsearch, or S3 to save audit logs.
Apache Ranger 2.5.0 and greater include the required Trino service definition. Earlier versions of Apache Ranger require an update to the service definition available on GitHub.

Configuration#

To use only Ranger for access control, create the file etc/access-control.properties on the coordinator, with the following configuration, and configurations listed in the table below:

access-control.name=ranger

To combine Ranger access control with file-based or other access control systems, follow the instructions about Multiple access control systems.

The following table lists the configuration properties for the Ranger access control:

Ranger access control configuration properties#
Name	Description
`ranger.service.name`	Name of the service on Ranger with the policies to enforce.
`ranger.plugin.config.resource`	Comma-separated list of Ranger plugin configuration files. Relative paths are resolved dynamically by searching on the classpath.
`ranger.hadoop.config.resource`	Comma-separated list of Hadoop configuration files. Relative paths are resolved dynamically by searching on the classpath.

ranger-trino-security.xml#

<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration xmlns:xi="http://www.w3.org/2001/XInclude">
  <property>
    <name>ranger.plugin.trino.policy.rest.url</name>
    <value>https://ranger-hostname:6182</value>
    <description>MANDATORY: a comma separated list of URLs to Apache Ranger instances in a deployment</description>
  </property>

  <property>
    <name>ranger.plugin.trino.access.cluster.name</name>
    <value></value>
    <description>Name to identify the cluster running the Trino instance. This is recorded in audit logs generated by the plugin</description>
  </property>

  <property>
    <name>ranger.plugin.trino.use.rangerGroups</name>
    <value>false</value>
    <description>Boolean flag to specify whether user-to-groups mapping should be obtained from in Apache Ranger. Default: false</description>
  </property>

  <property>
    <name>ranger.plugin.trino.use.only.rangerGroups</name>
    <value>false</value>
    <description>Boolean flag. true: use only user-to-groups mapping from Apache Ranger; false: use user-to-groups mappings from Apache Ranger and Trino. Default: false</description>
  </property>

  <property>
    <name>ranger.plugin.trino.super.users</name>
    <value></value>
    <description>Comma separated list of user names. Superusers will be authorized for all accesses, without requiring explicit policy grants.</description>
  </property>

  <property>
    <name>ranger.plugin.trino.super.groups</name>
    <value></value>
    <description>Comma separated list of group names. Users in supergroups will be authorized for all accesses, without requiring explicit policy grants</description>
  </property>

  <property>
    <name>ranger.plugin.trino.ugi.initialize</name>
    <value>false</value>
    <description>Initialize the kerberos identity used to authenticate with Ranger admin server</description>
  </property>

  <property>
    <name>ranger.plugin.trino.ugi.login.type</name>
    <value></value>
    <description>Valid value: keytab</description>
  </property>

  <property>
    <name>ranger.plugin.trino.ugi.keytab.principal</name>
    <value></value>
    <description>Kerberos principal. Example: [email protected]</description>
  </property>

  <property>
    <name>ranger.plugin.trino.ugi.keytab.file</name>
    <value></value>
    <description>Location of keytab file. Example: /etc/trino/trino.keytab</description>
  </property>
</configuration>

ranger-trino-audit.xml#

<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration xmlns:xi="http://www.w3.org/2001/XInclude">
  <property>
    <name>xasecure.audit.is.enabled</name>
    <value>true</value>
    <description>Boolean flag to specify if the plugin should generate access audit logs. Default: true</description>
  </property>

  <property>
    <name>xasecure.audit.solr.is.enabled</name>
    <value>false</value>
    <description>Boolean flag to specify if audit logs should be stored in Solr. Default: false</description>
  </property>

  <property>
    <name>xasecure.audit.solr.solr_url</name>
    <value></value>
    <description>URL to Solr deployment where the plugin should send access audits to</description>
  </property>

  <property>
    <name>xasecure.audit.destination.elasticsearch</name>
    <value>disabled</value>
    <description>Is es audit enabled? Allowed values to enable: enable, enabled, true</description>
  </property>

  <property>
    <name>xasecure.audit.destination.elasticsearch.urls</name>
    <value>host1,host2</value>
    <description>Comma (,) separated list of es hosts.</description>
  </property>
  
  <property>
    <name>xasecure.audit.destination.elasticsearch.index</name>
    <value>ranger_audits_write</value>
    <description>The index to write audits to. Default: ranger_audits</description>
  </property>

  <property>
    <name>xasecure.audit.destination.elasticsearch.port</name>
    <value>9200</value>
    <description>The port for es. Default: 9200</description>
  </property>

  <property>
    <name>xasecure.audit.destination.elasticsearch.protocol</name>
    <value>http</value>
    <description>The http protocol to use during communication. Default: http</description>
  </property>

  <property>
    <name>xasecure.audit.destination.elasticsearch.user</name>
    <value>write_user</value>
    <description>The username to authenticate towards es.</description>
  </property>

  <property>
    <name>xasecure.audit.destination.elasticsearch.password</name>
    <value>changeme</value>
    <description>The password to authenticate towards es.</description>
  </property>

</configuration>

ranger-policymgr-ssl.xml#

<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration xmlns:xi="http://www.w3.org/2001/XInclude">
  <!-- properties used for 2-way SSL between the Trino plugin and Apache Ranger server -->
  <property>
    <name>xasecure.policymgr.clientssl.keystore</name>
    <value></value>
    <description>Path to keystore file. Only required for two-way SSL. This property should not be included for one-way SSL</description>
  </property>

  <property>
    <name>xasecure.policymgr.clientssl.keystore.type</name>
    <value>jks</value>
    <description>Type of keystore. Default: jks</description>
  </property>

  <property>
    <name>xasecure.policymgr.clientssl.keystore.credential.file</name>
    <value></value>
    <description>Path to credential file for the keystore; the credential should be in alias sslKeyStore. Only required for two-way SSL. This property should not be included for one-way SSL</description>
  </property>

  <property>
    <name>xasecure.policymgr.clientssl.truststore</name>
    <value></value>
    <description>Path to truststore file</description>
  </property>

  <property>
    <name>xasecure.policymgr.clientssl.truststore.type</name>
    <value>jks</value>
    <description>Type of truststore. Default: jks</description>
  </property>

  <property>
    <name>xasecure.policymgr.clientssl.truststore.credential.file</name>
    <value></value>
    <description>Path to credential file for the truststore; the credential should be in alias sslTrustStore</description>
  </property>
</configuration>

Required policies#

Description	Resource	User	Permission(s)
Users must have permission to execute queries in Trino. Without a policy in Apache Ranger to grant this permission, users are not able to execute any query.	Query ID `*`	`{USER}`	`execute`
Users must have permission to impersonate themselves in Trino. Without a policy in Apache Ranger to grant this permission, users are not able to execute any query.	Trino User `{USER}`	`{USER}`	`impersonate`
External clients can use the `system.runtime.kill_query()` procedure to kill running queries.	Schema `system` Database `runtime` Procedure `kill_query`	`{USER}`	`execute`
(Optional) In order to perform a graceful shutdown of a worker, a separate user can be created. Note that it is possible to set up an additional password file authentication for this.	System Information	Any	`write_sysinfo`
(Optional) In order to retrieve metrics from the `/metrics` endpoint, a special user can be created. Note that it is possible to set up an additional password file authentication for this.	System Information	Any	`read_sysinfo`