Enabling Sentry in Cloudera Search for CDH 5
You can enable Sentry using Cloudera Manager or by manually modifying files. For more information on enabling Sentry using Cloudera Manager, see Configuring Sentry Policy File Authorization Using Cloudera Manager and Enabling Sentry Authorization for Solr.
- If you are using configs, you must configure the proper config=myConfig permissions as described in Using Roles and Privileges with Sentry.
- In a Cloudera Manager deployment, these properties are added automatically when you click Enable Sentry Authorization in the Solr configuration page in Cloudera Manager.
- In a deployment not managed by Cloudera Manager, you must make these changes yourself. The variable SOLR_AUTHORIZATION_SENTRY_SITE specifies the path to
sentry-site.xml. The variable SOLR_AUTHORIZATION_SUPERUSER specifies the first part of SOLR_KERBEROS_PRINCIPAL. This is solr for the majority of users, as solr is the default. Settings are of the form:
SOLR_AUTHORIZATION_SENTRY_SITE=/location/to/sentry-site.xml SOLR_AUTHORIZATION_SUPERUSER=solr
To enable sentry collection-level authorization checking on a new collection, the instancedir for the collection must use a modified version of solrconfig.xml with Sentry integration. Each collection has a separate solrconfig.xml file, meaning you can define different behavior for each collection. The command solrctl instancedir --generate generates two versions of solrconfig.xml: the standard solrconfig.xml without sentry integration, and the sentry-integrated version called solrconfig.xml.secure. To use the sentry-integrated version, replace solrconfig.xml with solrconfig.xml.secure before creating the instancedir.
You can enable Sentry on an existing collection. The process varies depending on whether you are using a config or instancedir.
Enabling Sentry on Collections using configs
If you have a collection that is using a non-secured config, you can enable Sentry security on that collection by modifying the collection to use a secure config. The config in use must not be immutable, otherwise it cannot be changed. To update an existing non-immutable config:
- Delete the existing config using the solrctl config --delete command. For example:
solrctl config --delete myManaged
- Create a new non-immutable config using the solrctl config --create command. Use a sentry-enabled template such as managedTemplateSecure. The new config must have the same name as the config being replaced. For example:
solrctl config --create myManaged managedTemplateSecure -p immutable=false
- Reload the collection using to solrctl collection --reload command.
solrctl collection --reload myCollection
For a list of all available config templates, see Included Immutable Config Templates.
Enabling Sentry on Collections using instancedirs
If you have a collection that is using a non-secured instancedir configuration, you can enable Sentry security on that collection by modifying the settings that are stored in instancedir. For example, you might have an existing collection named foo and a standard solrconfig.xml. By default, collections are stored in instancedirs that use the collection's name, which is foo in this case.
If your collection uses an unmodified solrconfig.xml file, you can enable Sentry by replacing the existing the solrconfig.xml file. If your collection uses a solrconfig.xml that contains modifications you want to preserve, you can attempt to use a difftool to find an integrate changes in to the secure template.
To enable Sentry on an existing collection without preserving customizations
# generate a fresh instancedir solrctl instancedir --generate foosecure # download the existing instancedir from ZK into subdirectory foo solrctl instancedir --get foo foo # replace the existing solrconfig.xml with the sentry-enabled one cp foosecure/conf/solrconfig.xml.secure foo/conf/solrconfig.xml # update the instancedir in ZK solrctl instancedir --update foo foo # reload the collection solrctl collection --reload foo
To enable Sentry on an existing collection and preserve customizations
Generate a new instancedir, compare the differences between the default solrconfig.xml and solrconfig.xml.secure files, and then add the elements that are unique to solrconfig.xml.secure to the file that your environment is using.
- Generate a fresh instancedir:
solrctl instancedir --generate foo
- Compare the solrconfig.xml and solrconfig.xml.secure:
diff foo/conf/solrconfig.xml foo/conf/solrconfig.xml.secure
- Add the elements that are unique to solrconfig.xml.secure to your existing solrconfig.xml file. You might complete this process by manually editing your existing solrconfig.xml file or by using a merge tool.
- Reload the collection:
solrctl collection --reload foo