If you are using the Sentry service (instead of a Sentry policy file), policies for Solr can be managed using the solrctl sentry command. To use this functionality, you must first designate a Sentry admin.

In Cloudera Manager:

1. Navigate to the Sentry service configuration page (Sentry service > Configuration).
2. In the Admin Groups field, add the name of a group to which you want to grant Sentry admin rights.
3. In the Allowed Connecting Users field, add the users to which you want to grant Sentry admin rights. These users must be members of at least one of the groups specified in the Admin Groups field.
4. Click Save Changes.
5. Restart the Sentry service (Sentry service > Actions > Restart).

If you are using the Sentry service without Cloudera Manager:

1. Edit sentry-site.xml file as follows:
   1. Add the Sentry admin group to the comma-separated list of groups in the sentry.service.admin.group property.
   2. Add the Sentry admin users to the comma-separated list of users in the sentry.service.allow.connect property.
2. Restart the Sentry service:

   bin/sentry --command service --conffile /path/to/sentry-site.xml

Sentry uses a role-based privilege model. A role is assigned a set of rules for accessing a given Solr collection or Solr config. Access to each collection is controlled by three privileges: Query, Update, and *. The wildcard (*) privilege indicates all privileges.

The admin collection is a special collection used to represent administrative actions. A non-administrative request may only require privileges on the collection or config on which the request is being performed. An administrative request generally requires privileges on both the admin collection and the collection on which the action is being performed. For more information on the privilege model for Search, including a mapping of actions to privilege requirements, see Authorization Privilege Model for Solr.

In contrast, access to config objects is controlled by a single privilege, *, meaning all privileges.

You can also use the wildcard (*) to specify all config objects or collections when granting privileges. The following example syntax applies to both native Sentry privileges and file-based privileges, though native Sentry privileges are set by using solrctl sentry commands as shown in Using Solr with the Sentry Service, and file-based privileges are set in policy files as shown in Using Solr with a Policy File.

For example:

• A rule for the Query privilege on collection named logs is formulated as follows:

  collection=logs->action=Query

• A rule for the * privilege, meaning all privileges, on the config named myConfig is formulated as follows:

  config=myConfig->action=*

  No action implies *. Because config objects only support the * action, the following config privilege is invalid:

  config=myConfig->action=Update

• A rule granting all collections the Query privilege is formulated as follows:

  collection=*->action=Query

myRole = collection=myCollection->action=QUERY, config=myConfig->action=*

engineer_role = collection=hive_logs->action=Query, collection=hbase_logs->action=Query, collection=current_bugs->action=Update

• A user is an entity that is permitted by the Kerberos authentication system to access the Search service.
• A group connects the authentication system with the authorization system. It is a set of one or more users who have been granted one or more authorization roles. Sentry allows a set of roles to be configured for a group.
• A configured group provider specifies how group membership is determined. Sentry supports HDFS-backed groups and locally configured groups. For example,

  dev_ops = dev_role, ops_role

Here the group dev_ops is granted the roles dev_role and ops_role. The members of this group can perform the actions that are allowed by these roles.

Using the Sentry Service with Cloudera Search can introduce latency because authorization requests must be sent to the Sentry Service. To alleviate this latency, enable caching by adding the following property to sentry-site.xml on each Solr Server:

<property>
  <name>sentry.provider.backend.generic.cache.enabled</name>
  <value>true</value>
</property>

By default, this caches Sentry responses for 30 seconds. To modify the cache duration, add the following property to sentry-site.xml on each Solr Server:

<property>
  <name>sentry.provider.backend.generic.cache.ttl.ms</name>
  <value>30000</value>
</property>

The value is set in milliseconds.

For Cloudera Manager environments, add these properties to the Advanced Configuration Snippet for sentry-site.xml:

1. Go to Solr service > Configuration > Advanced > Solr Service Advanced Configuration Snippet (Safety Valve) for sentry-site.xml.
2. Click the Add button.
3. Enter the following values:
   • Name: sentry.provider.backend.generic.cache.enabled
   • Value: true
4. Click the Add button.
5. Enter the following values:
   • Name: sentry.provider.backend.generic.cache.ttl.ms
   • Value: 30000
6. Click Save Changes.
7. Restart the Solr service (Solr service > Actions > Restart).

This section provides sample configurations.

This section contains notes on creating and maintaining the policy file.

For role-based access control of a collection, an administrator modifies a Sentry role so it has query, update, or administrative access.

Collection-level authorization is useful when the access control requirements for the documents in the collection are the same, but users may want to restrict access to a subset of documents in a collection. This finer-grained restriction can be achieved by defining separate collections for each subset, but this is difficult to manage, requires duplicate documents for each collection, and requires that these documents be kept synchronized.

Document-level access control solves this issue by associating authorization tokens with each document in the collection. This enables granting Sentry roles access to sets of documents in a collection.

Document-Level Security Model

Document-level security depends on a chain of relationships between users, groups, roles, and documents.

• Users are assigned to groups.
• Groups are assigned to roles.
• Roles are stored as "authorization tokens" in a specified field in the documents.

Document-level security supports restricting which documents can be viewed by which users. Access is provided by adding roles as "authorization tokens" to a specified document field. Conversely, access is implicitly denied by omitting roles from the specified field. In other words, in a document-level security enabled environment, a user might submit a query that matches a document; if the user is not part of a group that has a role has been granted access to the document, the result is not returned.

For example, Alice might belong to the administrators group. The administrators group may belong to the doc-mgmt role. A document could be ingested and the doc-mgmt role could be added at ingest time. In such a case, if Alice submitted a query that matched the document, Search would return the document, since Alice is then allowed to see any document with the "doc-mgmt" authorization token.

Similarly, Bob might belong to the guests group. The guests group may belong to the public-browser role. If Bob tried the same query as Alice, but the document did not have the public-browser role, Search would not return the result because Bob does not belong to a group that is associated with a role that has access.

Note that collection-level authorization rules still apply, if enabled. Even if Alice is able to view a document given document-level authorization rules, if she is not allowed to query the collection, the query will fail.

Roles are typically added to documents when those documents are ingested, either using the standard Solr APIs or, if using morphlines, the setValues morphline command.

Enabling Document-Level Security

Cloudera Search supports document-level security in Search for CDH 5.1 and higher. Document-level security requires collection-level security. Configuring collection-level security is described earlier in this topic.

Document-level security is disabled by default, so the first step in using document-level security is to enable the feature by modifying the solrconfig.xml.secure file. Remember to replace the solrconfig.xml with this file, as described in Enabling Solr as a Client for the Sentry Service Using the Command Line.

To enable document-level security, change solrconfig.xml.secure. The default file contents are as follows:

<searchComponent name="queryDocAuthorization">
    <!-- Set to true to enabled document-level authorization -->

    <bool name="enabled">false</bool>


    <!-- Field where the auth tokens are stored in the document -->
    <str name="sentryAuthField">sentry_auth</str>


    <!-- Auth token defined to allow any role to access the document.
         Uncomment to enable. -->

    <!--<str name="allRolesToken">*</str>-->

</searchComponent>

• The enabled Boolean determines whether document-level authorization is enabled. To enable document level security, change this setting to true.
• The sentryAuthField string specifies the name of the field that is used for storing authorization information. You can use the default setting of sentry_auth or you can specify some other string to be used for assigning values during ingest.
    Note: This field must exist as an explicit or dynamic field in the schema for the collection you are creating with document-level security. sentry_auth exists in the default schema.xml, which is automatically generated and can be found in the same directory as solrconfig.xml.

  for the collection you are creating with document-level security. Schema.xml is in the generated configuration in the same directory as the solrconfig.xml

• The allRolesToken string represents a special token defined to allow any role access to the document. By default, this feature is disabled. To enable this feature, uncomment the specification and specify the token. This token should be different from the name of any sentry role to avoid collision. By default it is "*". This feature is useful when first configuring document level security or it can be useful in granting all roles access to a document when the set of roles may change. See Best Practices for additional information.

org.apache.lucene.search.BooleanQuery$TooManyClauses: maxClauseCount is set to 1024

<maxBooleanClauses>2048</maxBooleanClauses>

Secure impersonation allows a user to make requests as another user in a secure way. The user who has been granted impersonation rights receives the same access as the user being impersonated.

Configure custom security impersonation settings using the Solr Service Environment Advanced Configuration Snippet (Safety Valve). For example, to allow the following impersonations:

• User hue can make requests as any user from any host.
• User foo can make requests as any member of group bar, from host1 or host2.
  Enter the following values into the Solr Service Environment Advanced Configuration Snippet (Safety Valve):

  SOLR_SECURITY_ALLOWED_PROXYUSERS=hue,foo
  SOLR_SECURITY_PROXYUSER_hue_HOSTS=*
  SOLR_SECURITY_PROXYUSER_hue_GROUPS=*
  SOLR_SECURITY_PROXYUSER_foo_HOSTS=host1,host2
  SOLR_SECURITY_PROXYUSER_foo_GROUPS=bar

SOLR_SECURITY_ALLOWED_PROXYUSERS lists all of the users allowed to impersonate. For a user x in SOLR_SECURITY_ALLOWED_PROXYUSERS, SOLR_SECURITY_PROXYUSER_x_HOSTS list the hosts x is allowed to connect from to impersonate, and SOLR_SECURITY_PROXYUSERS_x_GROUPS lists the groups that the users is allowed to impersonate members of. Both GROUPS and HOSTS support the wildcard * and both GROUPS and HOSTS must be defined for a specific user.

  Note: Cloudera Manager has its own management of secure impersonation for Hue. To add additional users for Secure Impersonation, use the environment variable safety value for Solr to set the environment variables as above. Be sure to include hue in SOLR_SECURITY_ALLOWED_PROXYUSERS if you want to use secure impersonation for hue.