Before you start developing applications on MapR’s Converged Data Platform, consider how you will get the data onto the platform, the format it will be stored in, the type of processing or modeling that is required, and how the data will be accessed.

A MapR Ecosystem Pack (MEP) provides a set of ecosystem components that work together on one or more MapR cluster versions. Only one version of each ecosystem component is available in each MEP. For example, only one version of Hive and one version of Spark is supported in a MEP.

The default security configuration uses MapR-SASL (tickets) for authentication, authorization, and encryption to automatically secure the MapR cluster and ecosystem components when you install them manually or using the MapR Installer.

Impersonation allows a service to act on behalf of a client while performing the action requested by the client. By default, user impersonation is disabled in Drill. You can configure user impersonation in the /opt/mapr/drill/drill-<version>/drill-override.conf file.

Drill supports authentication and encryption through the MapR Security (tickets) security mechanism. Authentication is the process of establishing confidence of authenticity. Encryption is the process of converting information or data from plain text into ciphertext to prevent unauthorized access. An administrator can manually configure Drill to use MapR Security. When MapR Security is enabled, all Drill clients, such as JDBC and ODBC, must connect to Drillbits through MapR Security.

Drill on MapR supports Kerberos v5 network security authentication and encryption. Kerberos is a network authentication protocol built on symmetric-key cryptography. Kerberos eliminates the need to store passwords locally or send them over the network and reduces the risk of impersonation.

An administrator can configure Drill to use the Linux pluggable authentication module (PAM) for Plain (username and password) authentication. PAM provides an authentication module that interfaces with any installed PAM authentication entity, such as the local operating system password file (/etc/passwd) or LDAP.

You can enable SSL for Drill in a secure or unsecure MapR cluster. SSL (Secure Sockets Layer), more recently called TLS, is a security mechanism that encrypts data passed between the Drill client and Drillbit (server). SSL also provides one-way authentication through which the Drill client verifies the identity of the Drillbit.

When Drill is installed on MapR clusters with the default security enabled, authentication is enabled between the Drillbits and ZooKeeper. The ZooKeeper znode information is secured automatically through authentication and znode ACLs. Communication between the Drillbits and Zookeeper is not encrypted.

Drill 1.13 and later supports the Simple and Protected GSS-API Negotiation mechanism (SPNEGO) to extend the Kerberos-based single sign-on authentication mechanism to HTTP. An administrator configures the web server (Drillbit) to use SPNEGO for authentication. Depending on the system, either the administrator or the user configures the client (web browser or web client tool) to use SPNEGO for authentication.

MapR-DB provides a highly scalable key-value database platform on which you can run SQL queries using Drill. As of the 6.0 release of the MapR Converged Data Platform, MapR-DB natively supports indexes on secondary fields in JSON tables.

MapR supports public APIs for MapR-FS, MapR-DB, and MapR-ES. These APIs are available for application development purposes.

Securing Drill

An administrator can install Drill with the default security configuration provided by
MapR or manually configure custom security for Drill.

Drill supports several security features that secure the communication paths between Drill
clients (such as ODBC/JDBC) and
Drillbits and also between Drillbits. The following sections briefly describe the security
configuration options for Drill and provide links to additional information and instructions.

MapR Default Security Configuration

Starting in MapR 6.0 and Drill 1.11 (MEP 4.0), Drill is automatically secured
when you install Drill on a MapR cluster that was installed with the default MapR security
configuration. The default MapR security configuration provides authentication,
authorization, and encryption through the MapR-SASL mechanism, except for HTTPS, which uses
SSL/TLS with
form-based authentication.

Note: The default MapR security configuration does not include
Kerberos or Plain authentication, however you can manually configure these security
mechanisms in addition to the default MapR security configuration.

Security Features Supported in a Custom Configuration

Drill supports several security features that an administrator can manually
configure to secure the communication paths between the Drill client, such as ODBC and JDBC,
and Drillbit and also between Drillbits. See Drill Drivers for ODBC and JDBC
driver information.

The following table lists the security features and mechanisms supported by Drill, as well
as the communication paths secured by each mechanism:

Note: In the following table, Drill
client refers to the Drill ODBC and JDBC clients.

Views and File ACEs

In additiona to the listed security features, you can create
views on data to limit access to data. You can also create file ACEs on the view
definition files to protect the views.

Roles and PrivilegesDrill has USER and ADMIN roles. Each role can perform different functions in Drill.

Drill Default Security The default security configuration uses MapR-SASL (tickets) for authentication, authorization, and encryption to automatically secure the MapR cluster and ecosystem components when you install them manually or using the MapR Installer.

User ImpersonationImpersonation allows a service to act on behalf of a client while performing the action requested by the client. By default, user impersonation is disabled in Drill. You can configure user impersonation in the /opt/mapr/drill/drill-<version>/drill-override.conf file.

MapR Security (Tickets)Drill supports authentication and encryption through the MapR Security (tickets) security mechanism. Authentication is the process of establishing confidence of authenticity. Encryption is the process of converting information or data from plain text into ciphertext to prevent unauthorized access. An administrator can manually configure Drill to use MapR Security. When MapR Security is enabled, all Drill clients, such as JDBC and ODBC, must connect to Drillbits through MapR Security.

KerberosDrill on MapR supports Kerberos v5 network security authentication and encryption. Kerberos is a network authentication protocol built on symmetric-key cryptography. Kerberos eliminates the need to store passwords locally or send them over the network and reduces the risk of impersonation.

Plain AuthenticationAn administrator can configure Drill to use the Linux pluggable authentication module (PAM) for Plain (username and password) authentication. PAM provides an authentication module that interfaces with any installed PAM authentication entity, such as the local operating system password file (/etc/passwd) or LDAP.

SSL/TLS for EncryptionYou can enable SSL for Drill in a secure or unsecure MapR cluster. SSL (Secure Sockets Layer), more recently called TLS, is a security mechanism that encrypts data passed between the Drill client and Drillbit (server). SSL also provides one-way authentication through which the Drill client verifies the identity of the Drillbit.

Security Between ZooKeeper and DrillbitsWhen Drill is installed on MapR clusters with the default security enabled, authentication is enabled between the Drillbits and ZooKeeper. The ZooKeeper znode information is secured automatically through authentication and znode ACLs. Communication between the Drillbits and Zookeeper is not encrypted.

SPNEGO for HTTP AuthenticationDrill 1.13 and later supports the Simple and Protected GSS-API Negotiation mechanism (SPNEGO) to extend the Kerberos-based single sign-on authentication mechanism to HTTP. An administrator configures the web server (Drillbit) to use SPNEGO for authentication. Depending on the system, either the administrator or the user configures the client (web browser or web client tool) to use SPNEGO for authentication.