Configuring Oozie on a Secure Cluster

IMPORTANT This component is deprecated. Hewlett Packard Enterprise recommends using an alternate product. For more information, see Discontinued Ecosystem Components.

The default configuration for Oozie on a secure cluster uses MapR tickets to authenticate between the Oozie client and server. The Oozie server uses tickets to authenticate the connection between the YARN components and the JobClient embedded in the Oozie server. Starting in the EEP 4.0 release, for secure clusters, Oozie is also configured to use SSL encryption. This default configuration is in place once Oozie is installed and the security features for your cluster are enabled. See Enabling and Disabling Security. No further configuration is required. See User Impersonation for Oozie to enable user impersonation for Oozie.

The sections below provide instructions to manually configure Oozie features on a secure cluster:

Oozie Server secured by default to use SSL

Starting in EEP 6.0.0, for Oozie 4.3.0 and above, Oozie server uses SSL by default for secured clusters.

  1. By default, on a secure cluster, Oozie reads the ssl-client.xml file and configures SSL using this file.
  2. If you want to use a custom SSL configuration, enable custom secure on your cluster.

Configuring the Oozie Server to use SSL (Oozie 5.1.0.0 and above)

Configure the settings necessary for enabling SSL or TLS support in the oozie-site.xml file.

  1. Set the oozie.https.enabled property to true: 
    <property>
  <name>oozie.https.enabled</name>
  <value>true</value>
  <description>Controls whether SSL encryption is enabled.</description>
</property>
                     
<property>
  <name>oozie.https.truststore.file</name>
  <value>/opt/mapr/conf/ssl_truststore</value>
  <description>Path to a TrustStore file.</description>
</property>
                     
<property>
  <name>oozie.https.keystore.file</name>
  <value>/opt/mapr/conf/ssl_keystore</value>
  <description>Path to a KeyStore file.</description>
</property>
                     
<property>
  <name>oozie.https.keystore.pass</name>
  <value><password></value>
  <description>Password to the KeyStore.</description>
</property>
    NOTE To configure the Oozie for http, set the oozie.https.enabled property to false.
  2. Connect to the Oozie Web UI using SSL (HTTPS): 
    https://oozie.server.hostname:11443/oozie

You can also encrypt the Oozie keystore password. For more information, refer to the open source documentation.

Configuring Oozie Clients to Use SSL (Oozie 4.3.0)

To configure the Oozie clients, follow this step:

  • Specify the path to the keystore and password at /opt/mapr/oozie/oozie-<version>/conf/oozie-client-env.sh: 
    export OOZIE_CLIENT_OPTS="${OOZIE_CLIENT_OPTS} -Djavax.net.ssl.trustStore=/opt/mapr/conf/ssl_truststore"

Using Kerberos to Securely Authenticate Between the Oozie Client and Server

Oozie can use Kerberos to secure authentication between the Oozie client and server. The Oozie server uses the Kerberos principal and keytab information specified in the Java Authentication and Authorization (JAAS) configuration file at /opt/mapr/conf/mapr.login.conf. Generate a Kerberos principal of the form http/ <fqdn>@<realm> and store the keytab in the cluster’s keytab file. The default keytab file location is /opt/mapr/conf/mapr.keytab.

To use Kerberos authentication on a specific invocation of Oozie without modifying your client, use the -auth KERBEROS option when you start Oozie, as in the following example:

$ bin/oozie admin -status -auth KERBEROS

Defining a Custom Principal and Keytab File

You can use custom Kerberos principals and keytab files if you wish. To specify the locations of these custom Kerberos principals and keytab files, make the following modifications to the oozie-site.xml file:

  • Explicitly change the authentication type to Kerberos.

    <property>
    <name>oozie.authentication.type</name>
    <value>kerberos</value>
    <description>
    Defines authentication used for Oozie HTTP endpoint.
    Supported values are: simple | kerberos | #AUTHENTICATION_HANDLER_CLASSNAME#
    </description>
</property>

  • Modify the following entries to use your custom principals and keytab. The principal takes the form HTTP/<hostname>, where hostname is the URL used by the client to connect to the server.

    <property>
    <name>oozie.service.HadoopAccessorService.keytab.file</name>
    <value>/opt/mapr/conf/mapr.keytab</value>
    <description>
      Location of the Oozie user keytab file.
    </description>
</property>

<property>
    <name>local.realm</name>
    <value>{local.realm}</value>
    <description>
      Kerberos Realm used by Oozie and Hadoop. Using 'local.realm' aligns with Hadoop configuration
    </description>
</property>

<property>
    <name>oozie.service.HadoopAccessorService.kerberos.principal</name>
    <value>mapr/<hostname>@${local.realm}</value>
    <description>
       Kerberos principal for Oozie service.
    </description>
</property>

<property>
    <name>oozie.authentication.kerberos.principal</name>
    <value>HTTP/<hostname>@${local.realm}</value>
    <description>
      Indicates the Kerberos principal to be used for the HTTP endpoint. The principal MUST start with 'HTTP/' per the Kerberos HTTP SPNEGO specification.
    </description>
</property>
  • Optional: If you plan to run Oozie actions that require talking to external services, add the oozie.credentials.credentialclasses to oozie-site.xml. For more details, see the Oozie documentation.
    <property>
    <name>oozie.credentials.credentialclasses</name>
    <value>
         hcat=org.apache.oozie.action.hadoop.HCatCredentials,
         hbase=org.apache.oozie.action.hadoop.HbaseCredentials,
         hive2=org.apache.oozie.action.hadoop.Hive2Credentials
    </value>
</property>
NOTE No specific configuration is required for configuring Oozie to use data-fabric-SASL.

Disabling Cached Tokens

After a client authenticates to Oozie, the authentication token received by the client is cached in the user’s home directory in the .oozie-auth-token file. As long as the cached token remains valid, future authentication requests from the same client use that token and succeed, even if the client’s Kerberos or credentials have expired or have been revoked. You can disable use of the cache file by using the oozie command-line interface with the -Doozie.auth.token.cache false option.