Audience: System Administrators
Content Summary: The Immuta CDH integration installation consists of the following components:
Immuta NameNode plugin
Immuta Hadoop Filesystem plugin
Immuta Spark 2 Vulcan service
This page outlines the installation steps required to successfully deploy these components on your CDH cluster.
Prerequisites: Follow the Immuta CDH Integration Prerequisites to prepare for installation.
Begin installation by transferring the Immuta .parcel and its associated .parcel.sha files to your Cloudera Manager node and placing them in /opt/cloudera/parcel-repo. Once copied, ensure files have both their owner and group permissions set to cloudera-scm
Next, transfer the Immuta CSD (.jar file) to /opt/cloudera/csd, and ensure both its owner and group permissions are set to cloudera-scm as well.
You will need to restart the Cloudera Manager server in order for the CSD to be picked up:
Follow Cloudera's instructions for distributing and activating the IMMUTA parcel.
Once the parcel has been successfully activated, you can add the IMMUTA service:
From the Cloudera Manager select Add Service.
Choose Immuta.
Click Continue.
Select nodes to install the services on. Your options are
For maximum redundancy, choose all.
Choose a single node.
Choose a few nodes. Set up a Load Balancer in front of the instances to distribute load. Contact Immuta support for more details.
Proceed to the end of the workflow.
After adding the Immuta service to your CDH cluster, there is some configuration that needs to be completed.
If your cluster is configured with Kerberos, note that the default configuration expects to run Immuta services using the immuta principal. If you need to use a different Kerberos principal, see Running as a Non-Default User for detailed instructions on how to configure that. After running through these steps, note that you may need to manually run the Create Immuta User Home Directory command from the Actions menu for the Immuta service.
For more details on Immuta's HDFS configuration, please see Hadoop Cluster Configuration for Immuta.
Warning
The following settings should only be written to the configuration on the NameNode. Setting these values on DataNodes will have security implications, so be sure that they are set in the NameNode only section of Cloudera Manager. For optimal performance, only set these configuration options in the NameNode Role Config Group that controls the namespace where Immuta data resides.
Under the HDFS service of Cloudera Manager, Configuration tab, search for key:
and, using "View as XML", add/set the value(s) similar to:
Best Practice: Configuration Values
Immuta recommends that all Immuta configuration values be marked final.
See Hadoop Cluster Configuration for Immuta for details about each individual configuration value.
The following configuration items should be configured for both the NameNode processes and the DataNode processes. These configurations are used both by the Immuta FileSystem and the Immuta NameNode plugin. For example:
Under the HDFS service of Cloudera Manager, Configuration tab, search for key:
and, using "View as XML", add/set the value(s) similar to:
Best Practice: Configuration Values
Immuta recommends that all Immuta configuration values be marked final.
Make sure that user directories underneath immuta.credentials.dir are readable only by the owner of the directory. If the user's directory doesn't exist and we create it, we will set the permissions to 700.
See Hadoop Cluster Configuration for Immuta for details about each individual configuration value.
You can enable TLS on the Immuta Vulcan service by configuring it to use a keystore in JKS format.
Under the Immuta service of Cloudera Manager, Configuration tab, search for key:
and, using "View as XML", add/set the value(s) similar to:
Best Practice: Configuration Values
Immuta recommends that all Immuta configuration values be marked final.
Detailed Explanation:
immuta.secure.partition.generator.keystore
Specifies the path to the Immuta Vulcan service keystore.
Example: /etc/immuta/keystore.jks
immuta.secure.partition.generator.keystore.password
Specifies the password for the Immuta Vulcan service keystore. This password will be a publicly available piece of information, but file permissions should be used to make sure that only the user running the service can read the keystore file.
Example: secure_password
immuta.secure.partition.generator.keystore.password
Specifies the password for the Immuta Vulcan service keystore. This password will be a publicly available piece of information, but file permissions should be used to make sure that only the user running the service can read the keystore file.
Example: secure_password
immuta.secure.partition.generator.keymanager.password
Specifies the KeyManager password for the Immuta Vulcan service keystore. This password will be a publicly available piece of information, but file permissions should be used to make sure that only the user running the service can read the keystore file. This is not always necessary.
Example: secure_password
Best Practice: Secure Keystore with File Permissions
Immuta recommends using file permissions to secure the keystore from improper access:
You must also set the following properties under the following client sections:
For Spark 2, under the Immuta service of Cloudera Manager, Configuration tab, search for key:
and, using "View as XML", add/set the value(s) similar to:
Best Practice: Configuration Values
Immuta recommends that all Immuta configuration values be marked final.
Detailed Explanation:
immuta.secure.partition.generator.keystore
Set to true to enable TLS
Default: true
You must give the service principal that the Immuta Web Service is configured to use permission to delegate in Impala. To accomplish this, add the Immuta Web Service principal to authorized_proxy_user_config in the Impala daemon command line arguments.
Under the Impala service of Cloudera Manager, Configuration tab, search for key:
and add/set the value(s) similar to:
If the authorized_proxy_user_config parameter is already present for other services, append the Immuta configuration value to the end:
No additional configuration is required.
Note: Immuta will work with any Spark 2 version you may have already installed on your cluster.
The Immuta Vulcan service requires the same system API key that is configured for the Immuta NameNode plugin. Be sure that the value of immuta.system.api.key is consistent across your configuration.
For Spark 2, under the IMMUTA service of Cloudera Manager, Configuration section, search for key:
and, using "View as XML", add/set the value(s) similar to:
Best Practice: Configuration Values
Immuta recommends that all Immuta configuration values be marked final.
The Immuta Web Service needs to be configured to support the HDFS plugin. You can set this configuration using the Immuta Configuration UI.
Though generally unnecessary given the configuration through the Application Settings of the Web UI, below is an example YAML snippet that can be used as an alternative to the Immuta Configuration UI if recommended by an Immuta representative.
Detailed Explanation:
client
kerberosRealm
Specifies the default realm to use for Kerberos authentication.
Example: YOURCOMPANY.COM
plugins
hdfsHandler
hdfsSystemToken
Token used by NameNode plugin to authenticate with the Immuta REST API. This must equal the value set in immuta.system.api.key. Use the value of HDFS_SYSTEM_TOKEN generated earlier.
Example: 0ec28d3f-a8a2-4960-b653-d7ccfe4803b3
kerberos
ticketRefreshInterval
Time in milliseconds to wait between kinit executions. This should be lower than the ticket refresh interval required by the Kerberos server.
Default: 43200000
username
User principal used for kinit.
Default: immuta
keyTabPath
The path to the keytab file on disk to be used for kinit.
Default: /etc/immuta/immuta.keytab
krbConfigPath
The path to the krb5 configuration file on disk.
Default: /etc/krb5.conf
krbBinPath
The path to the Kerberos installation binary directory.
Default: /usr/bin/
Additionally, you must upload a keytab for the immuta user as well as a krb5.conf configuration file to the Immuta Web Service. This can also be done via the Immuta Configuration UI.