Users and groups for secure impersonation

On the Hadoop cluster, the 

Assuming this group is named

• Create a Unix or LDAP group 

  D s defaultuser
  Type hadoop.group Value true

• Make user

  D s defaultuser
  Type hadoop

   a member of 

  D s defaultuser
  Type hadoop.group Value true

• Verify that all user principals that use the platform are also members of the

  D s defaultuser
  Type hadoop.group Value true

   group.

Hadoop configuration for secure impersonation

In your Kerberos configuration, you must configure the user

In core-site.xml on the Hadoop cluster, add the following configuration, replacing the values for

  <!-- Trifacta secure impersonation -->
  <property>
    <name>hadoop.proxyuser.[hadoop.user].hosts</name>
    <value>*</value>
  </property>
  <property>
    <name>hadoop.proxyuser.[hadoop.user].groups</name>
    <value>[hadoop.group]</value>
  </property>

HDFS Directories

Verify that the shared upload and job results directories are owned and writeable to the

For more information on HDFS directories and their permissions, see Prepare Hadoop for Integration with the Platform.

Stricter directory permissions in an impersonated environment

By default, the directories and sub-directories of the locations for uploaded data and job results are set to 730 in an environment with secure impersonation enabled. This configuration allows impersonated users to do the following: 

• The 7 user-permission implies that individual users have full permissions over their own directories.

  • Individual users can read only data in their own upload directory below /trifacta/uploads.

• The 3 user-permission is used because the top-level directory is owned by the

  D s defaultuser
  Type hadoop

  user. Each impersonated user in the

  D s defaultuser
  Type hadoop.group Value true

  group requires write and execute permissions on their own directory to create it and manage it. This permission set implies that the

  D s defaultuser
  Type hadoop.group Value true

  group has read and execute permissions over a user's upload directory.

• Without access-level controls, these permissions are inherited from the parent directory and have the following implications:

  • Since impersonated group users have execute permissions, they can list all directories in this area.

  • Since impersonated group users have write permissions, they can theoretically write to any other user's upload directory, although this directory is not configurable.

Within the upload area, each user of the

If access-level controls are enabled for your impersonated environment, you can apply stricter permissions on these sub-directories for additional security.

Steps:

The following steps apply 730 permissions to the top-level directory and 700 to all user sub-directories. With these stricter permissions on sub-directories, no one other than the user, including the

1. The /trifacta/uploads value is the default value for upload location in HDFS.

   1. In an individual deployment, the directory setting is defined in platform configuration .

      D s config

      Locate the value for hdfs.pathsConfig.fileUpload .
      

      Info
      NOTE: The following steps can also be applied to the directory where job results are written. By default, this directory is /trifacta/queryResults. For more secure controls over job results, you should also retrieve the value for hdfs.pathsConfig.batchResults.

       

   2. Replace the values in the following steps with the value from your configuration.

2. Before you begin, you should consider resetting all access-level controls on the upload directories and sub-directories:

   Code Block
   hdfs dfs -setfacl -b /trifacta/uploads

   
   

3. The following command removes the application of the permissions from the uploads directory and any sub-directory to members of the default group. So, an individual group member's permissions are not automatically shared with the group:

   Code Block
   hdfs dfs -setfacl -R -m default:group::--- /trifacta/uploads

   
   

4. The following command is required to enable all users to access dictionaries:

   Code Block
   hdfs dfs -setfacl -R -m default:group::rwx /trifacta/uploads/0

   
   

5. The following step sets the permissions at the top level to 730 :

   Code Block
   hdfs dfs -chmod 730 /trifacta/uploads

   
   

6. Sub-directory permissions are a combination of these permissions and any relevant access-level controls.

7. Apply to queryResults directory: Repeat the above steps for the /trifacta/queryResults directory as needed.

8. ACL for Hive: If you need to apply access controls to Hive, you can use the following:

   Code Block
   hdfs dfs -setfacl -R -m default:user:hive:rwx /trifacta/queryResults

   
   

User directories for YARN

For YARN deployments, each Hadoop user must have a home directory for which the user has write permissions. This directory must be located in the following location within HDFS:

/user/<username>

where:

• <username> is the Hadoop principal to use.

Example for Hadoop principal myUser:

hdfs dfs -mkdir /user/myUser
hdfs dfs -chown myUser /user/myUser

Optional:

hdfs dfs -chmod -R 700 /user/myUser

D s item
item configuration

for secure impersonation

Set the following parmeter to true.

"hadoopImpersonation" : true,

If you have enabled the Spark running environment for job execution, you must enable the following parameter as well:

"spark-job-service.sparkImpersonationOn" : true,

For more information, see Configure Spark Running Environment.

Umask permissions

Under secure impersonation, the 

Editing users