Security Support Matrix

This matrix shows the security support available for MapR Ecosystem projects.
MapR Version MEP Version
5.2 1.x and 2.x
5.1 N/A
5.0 N/A
4.1 N/A
4.0.x N/A
3.1.1 N/A
Auditing cuts across projects and is independent of security settings for individual projects. See Auditing Overview for a description of the features and instructions for implementation. In summary, MapR auditing supports the auditing functionality implemented in Hadoop open source components. It includes four audit types specific to MapR:
  • Administrative (or CLDB) auditing
  • Authentication auditing
  • MapR command line interface (maprcli) auditing
  • Data access auditing
In addition, auditing formats all audit records in JSON format to support analytics in Drill.

To simplify the information presented in the table below, only those items that you must consider are listed for each project. The following items must always be considered for each project:

  • Inbound Authentication
  • Inbound Encryption
The following items are typically determined by the receiver and are included where there are exceptions:
  • Outbound Authentication
  • Outbound Encryption
The following items are only listed for multi-component services for which they are relevant, such as HBase and Drill.
  • Authentication between Services
  • Encryption between Components
Impersonation is only listed for proxy services for which it is relevant, such as services that communicate with another service. Authorization is only listed for the service which authorizes itself; other services are handled by impersonation.
Project Supported Security Options
Cascading None

Inbound Authentication:

  • user/password (PAM, Kerberos)
  • No internal authentication between daemons

Outbound Authentication: MapR ticket

Authentication between Services: None

Impersonation: Yes (with some data targets only, and file system/database access runs jobs as submitting user; see Drill Impersonation with Hive)

Authorization: None (relies on data store).

Views provide a way to securely share subsets of data, providing a form of access control.

Encryption over Wire: None

Encryption between Components: None


Inbound Authentication: N/A (not a service)

Outbound Authentication: MapR ticket, Kerberos

Authentication between Flume agents: MapR ticket, Kerberos

Impersonation: Yes (runs jobs as submitting user)

Authorization: N/A

Encryption over Wire: SSL from Thrift RPC 1.6.0 on

File Channel Encryption: Supported from Thrift RPC 1.6.0 on


Inbound Authentication: Kerberos

Impersonation: inbound

Authentication between Services: Kerberos

Authorization: ACLs on table, column family, and column; boolean logic on cells

Encryption over Wire: Kerberos (inbound and service-to-service; when communicating with another component, it honors that component’s encryption)

HBase/MapR-DB REST Proxy

Inbound Authentication: Kerberos, MapR ticket, custom

Impersonation: Yes, the user authenticates to Gateway, which then impersonates user to HBase/MapR-DB

Authorization: None (delegates to HBase/MapR-DB)

Built-in Data Authorization: No

Encryption over Wire: SSL

Encryption between Components: Kerberos

HBase/MapR-DB Thrift Proxy

Inbound Authentication: Kerberos, MapR ticket

Impersonation: Yes. Impersonation honors data authorization from HBase 0.98.7 onward.

Authorization: None (delegates to HBase/MapR-DB)

Built-in Data Authorization: No

Encryption over Wire: SSL


Hive Metastore:

Inbound Authentication: Kerberos, MapR-SASLAuthorization: storage-based


Inbound Authentication: user/password (PAM), Kerberos, MapR-SASL (enabled with cluster security), LDAP

Outbound Authentication: MapR ticket, Kerberos

Impersonation: Yes (By default it is turned off. HiveServer2 submits jobs as mapr user, since mapr is the default user that runs all Hive services: metastore and HiveServer2.)

Authorization: Built-in, standards-based, or delegate to HBase/MapR-DB

Encryption over Wire: Inbound

Hive transforms (custom MapReduce code) run as submitter via impersonation. So data level authorization applies, and Sentry level authorization does not.


Inbound Authentication: user/password (PAM), Kerberos


Inbound Authentication: user/password (PAM), MapR ticket (except CURL), Kerberos

Impersonation: Yes

Encryption: SSL

Encryption over Wire: Yes


Inbound Authentication: user/password (LDAP, file, PAM), Kerberos

Outbound Authentication, Hue 3.7 and greater: MapR-SASL, Kerberos (MapReduce v1, MapReduce v2/YARN)

Outbound Authentication, Hue 3.6 and greater: Kerberos (MapReduce v1, MapReduce v2/YARN)

Impersonation: Yes

Encryption over Wire: SSL

Enabling Hue security with MapR-SASL or Kerberos for connectivity to HiveServer2 requires that Hive Server 2 enable MapR-SASL and disable user/password. Thus user/password will not work with Hive Server 2 for ODBC/JDBC.

Enabling Hue to connect to HBase securely requires that HBase support Kerberos.


Inbound Authentication: Kerberos (only when MapR cluster security is disabled), LDAP

Outbound Authentication: Kerberos (only when MapR cluster security is disabled), LDAP

Impersonation: No (all file system/database access is as Impala daemon)

Authorization: Sentry required

Encryption over Wire: Yes

MapReduce v1 and v2 (YARN)

Inbound Authentication: MapR ticket (user/password or Kerberos for Web interfaces)

Outbound Authentication: MapR ticket

Authorization: ACLs on queues, jobs

Impersonation: Yes (runs jobs as submitting user)

Encryption over Wire: AES 256

Mahout Library1 (N/A-not a service)

Inbound Authentication: MapR ticket, Kerberos

Outbound Authentication: MapR ticket, Kerberos

Impersonation: Yes

Authorization: Yes

Encryption over Wire: Yes

Pig Library1 (N/A-not a service)
Sentry With Impala 1.4.1: Sentry 1.4.0 can provide authorization on a non-secure cluster or on a secure cluster where Hive does not use Kerberos authentication.

With Impala 2.2: Sentry 1.6.0 can provide authorization on a non-secure cluster or on a secure cluster that uses Kerberos authentication.

As of Sentry 1.6.0: Sentry can provide authorization with Sqoop2 on a secure Kerberos cluster.

Hive and Sentry integration is also supported on MapR-SASL and kerberized clusters.


Inbound Authentication: None for user, but daemons for an application can authenticate to each other

Outbound Authentication: MapR ticket (if started by YARN) (No security when Spark uses Thrift Gateway)

Impersonation: Yes (if started by YARN; Spark workers run as submitting user)

Authorization: N/A generally

Encryption over Wire: None

Configure Spark with YARN, then start a Spark application using YARN. YARN starts application workers on nodes and application connects to those workers. The workers access the cluster as submitting user. Optionally, configure network level authentication to enforce.

Sqoop 1.4.x

Library1 (N/A-not a service)

Sqoop 2.0.0

Inbound Authentication: Kerberos, MapR-SASL

Outbound Authentication: Kerberos, MapR-SASL

Authorization: Role-based access control from Sqoop 1.99.6 on Sentry

Impersonation: Yes (Kerberos only)

Encryption over Wire: Starting with 1.99.7


Inbound Authentication: Kerberos

Outbound Authentication: Kerberos

Authorization: Yes (topologies in web user interface)

Impersonation: Yes (runs workers as submitting user)

Encryption over Wire: SSL to web user interface and SASL for ZooKeeper

Tez (Developer Preview) None
ZooKeeper Authentication: MapR ticket

Encryption over Wire: None


1 For libraries, security depends on the user of the library.

See the following sections for related information on MapR security:

  • For technical information on the the protocols supported by MapR, see Security Protocols
  • For a list of supported ecosystem projects and versions for a given version of the MapR distribution, see the Ecosystem Support Matrix.
  • For an overview of security in MapR, with instructions for implementing various features for the core components, see the Security Overview.
  • For instructions on implementing security features for specific ecosystem components, see the section for the component in the Ecosystem Components.