Managing Impersonation

Example: Access Control and Impersonation

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 any user's servicewithimpersonation ticket to authenticate with the datastore - file system/HPE Ezmeral Data Fabric Database.
5. The datastore authenticates the user with the impersonation ticket. 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 Data Fabric:

• 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 filesystem permissions on servers where Data Fabric components reside, have no effect on user access to Data Fabric resources.
• The mapr superuser is allowed to impersonate any Data Fabric user in any group, connecting from any host. Other users with impersonation capability can impersonate any Data Fabric user in any group, except the mapr superuser and the root user.

Using Impersonation without Security

Although it is possible to enable impersonation in a non-secure Data Fabric installation, HPE strongly recommends against doing this. The implementation rules are different. Setting up the Data Fabric environment with impersonation operating under those rules makes it very difficult to enable security later. Disabling security in a secure Data Fabric installation is easy, if the need arises.

If you choose to implement impersonation in a non-secure Data Fabric cluster, see Configuring Impersonation when Cluster Security is not Enabled.

Using Impersonation with Security

In general, this documentation assumes that security is enabled in your Data Fabric installation. See Enabling Wire-level Security and Enabling Encryption of Data at Rest.

You can use the maprlogin utility to generate a servicewithimpersonation ticket that can be used to access a secure cluster impersonating another user. That is, the servicewithimpersonation ticket provides the user the ability to impersonate other users (except the mapr user) in addition to the ability to access a secure cluster. The servicewithimpersonation ticket generated with the list of impersonatedgids and impersonateduids cannot be used to impersonate user root or user mapr. If the user is other than root or mapr, CLDB resolves the username to UID locally. It then checks if the resolved UID can be impersonated (that is, if it is a part of the ticket's impersonateduids) or at least one of the GIDs of the resolved UID can be impersonated (i.e., if at least one of the GIDs should be part of the ticket's impersonatedgids). The servicewithimpersonation ticket can only be generated by a user with full control on a cluster's ACL.

If you are setting up user impersonation in a secure cluster, you need to generate an impersonation ticket. See the Generating and Printing Service with Impersonation Ticket section in the maprlogin Command Examples topic and Generating a Service with Impersonation Ticket for information.