MapR 5.0 Documentation : Access Control and Impersonation in MapR

As an example of impersonation, consider user Bob and a generic Service X:

  1. Bob launches a client for the service and may or may not provide credentials.

  2. Service X authenticates Bob and establishes a connection for him to use.

  3. Bob issues a command to the service that will produce a query.

  4. The service uses the mapr superuser to authenticate with the datastore - MapR-FS/MapR-DB or HBase.

  5. The datastore authenticates the mapr superuser - the service can now proceed.

  6. The service sends the datastore a query, as user Bob.

  7. The datastore checks permissions for Bob on the assets that the query will access.

  8. If Bob has permissions, the datastore returns the query results to the service, which relays the results to the client, and the query succeeds.

  9. If Bob does not have permissions, the datastore sends an access error to the service, which relays the error to the client, and the query fails.

When you use impersonation in MapR:

  • The datastore permissions are authoritative.

  • The process has end-to-end security.

  • Users can do nothing more and nothing less than what they are authorized to do.

  • This control is independent of remote authentication and security mechanisms that control user access to application features.

  • Any permissions set up within applications, or within the UNIX file system permissions on servers where MapR components reside, have no effect on user access to MapR resources.

  • The mapr superuser is allowed to impersonate any MapR user in any group, connecting from any host.

Using Impersonation without Enabling Security

Although it is possible to enable impersonation in an insecure MapR installation, MapR strongly recommends against doing this. The implementation rules are different, and setting up the MapR environment with impersonation operating under those rules makes it very difficult to enable security at a later date. Disabling security in a secure MapR installation is easy, if the need arises.

If you choose to implement impersonation in an insecure MapR cluster, see Configuring Impersonation when Cluster Security is not Enabled. In general, the documentation of impersonation in this Security Guide assumes that security is enabled in your MapR installation. See Enabling and Disabling Security Features on Your Cluster.

How Impersonation Works in MapR

When the mapr superuser attempts to impersonate another user to the MapR-FS or MapR-DB systems:

  1. The MapR client looks for that user name in the local operating system registry.

  2. If the user name is found, MapR sends the user’s UID and GID to the server for impersonation.

    If the user name is not found in the local operating system registry, the user action is not processed.

Limitations on Impersonation

Impersonation does not work in MapR when you are accessing:

  • MapR-FS or MapR-DB through a MapR client running on Windows.

  • MapR-FS from C/C++. (You can access MapR-DB from C/C++.)

  • MapR-FS or MapR-DB, if you attempt to have any user other than the MapR superuser impersonate another user.

Core Requirements for Impersonation

Only the mapr superuser is allowed to access to the MapR-FS and MapR-DB systems. Three conditions must be met in order for the mapr superuser to be able to impersonate another MapR user:

  1. The hadoop.proxyuser.mapr.groups and hadoop.proxyuser.mapr.hosts  parameters must be set correctly in the core-site.xml file.

    See Enabling Impersonation for the mapr Superuser

    These settings are not always required. If the MapR client accesses an ecosystem component, such as JobTracker or HiveServer2, these settings may be required. These settings are never needed when the MapR client accesses MapR-FS or MapR-DB directly. Enabling impersonation here ensures that the correct settings are in place if they are needed.

  2. The name of the MapR user that you want the mapr superuser to be able to impersonate must appear in the local operating system registry where the MapR client is running.  

  3. The UID and GUID of the user name under which the MapR client is running must match exactly the UID and GUID for that user name on the server.

Component Requirements for Impersonation

Some MapR ecosystem components have additional requirements to enable impersonation.

The following components must have settings that support impersonation in the configuration files indicated, on each node where the component resides:

  • Drill: Edit the drill-env.sh file. See Configuring User Impersonation in the Apache Drill documentation.

  • Flume: Edit the flume.conf file. See “Flume and Impersonation” section of Configuring Flume on a Secure Cluster.

  • HBase: Edit the hbase­-site.xml file. See “Enabling Impersonation on a Secure Cluster” section of Impersonation via the HBase REST Gateway.

  • HiveServer2: hive-site.xml file. See Hive User Impersonation.

  • Hue: Edit the hue.ini file. See “Modifying the hue.ini File” section of Integrate Hue with Impala.

  • Impala: Does not support impersonation.

  • Oozie: Edit the oozie-site.xml file. See “User Impersonation” section of User Impersonation for Oozie.

  • Spark: No special settings are required for Spark in MapReduce 2 (YARN) mode, since Spark automatically inherits the correct behavior from YARN. When running standalone, Spark cannot perform impersonation and should not be used if security is important.

Application Development Requirements

You can set up impersonation in an application programmatically.