Password Encryption in Azkaban Configuration Files

Passwords in azkaban.local.properties and azkaban-users.xml can an should be protected. The azkaban.local.properties setting 'azkaban.passwordEncryption' determines the encryption method Azkaban  will use to decrypt during startup.

There are 3 available types of encryption that can be set in 'azkaban.passwordEncryption':

• NONE - passwords are in plain text
• DPAPI - passwords are encrypted using Windows DPAPI user based encryption then encoded as Unicode base-64 strings
• WALLET - passwords are plain text strings which represent the name of a credential in a scriptable password manager

Using Windows DPAPI Encryption

If you have a Windows based Azkaban Web server using DPAPI properties file password encryption then you will need to first encrypt your passwords with DPAPI using the Windows User that the Web Server Service runs under. See this section for creating the encrypted DPAPI base64 strings with PowerShell, or use the Encryption Utility to perform the same function.

Using WALLET Encryption

When using WALLET then you need to set a value for azkaban.walletCmd in azkaban.local.properties which is used as a system command to retrieve the password from the wallet or password manager. For more information on Wallet configuration using a standard Linux password manager, visit  https://www.passwordstore.org/

When using WALLET the passwords in the azkaban.local.properties and azkaban-users.xml file are just plain text strings that represent a credential name stored in the password manager. At run time Azkaban will execute the azkaban.walletCmd to retrieve the actual password for the given property.

Prior to executing the wallet command Azkaban will set the environment variable AZKABAN_WALLET_STRING to the property value to be looked up. Therefore if I was using the Linux password manager 'pass' from https://www.passwordstore.org/ my azkaban.walletCmd would be set to: 'pass $AZKABAN_WALLET_STRING'

Setting up Azkaban Users

If you require additional users for the Azkaban dashboard or API, other than the default users, then they can be added by the following process:

Create Azkaban accounts by editing the azkaban-users.xml file in the Web Server install directory, any changes to the settings in this file will not take effect until the Azkaban Web Server is restarted.

<web_server_dir>\<server_name>\azkaban-users.xml

For example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<azkaban-users>
  <role name="admin" permissions="ADMIN"/>
  <role name="read" permissions="READ"/>
  <role name="executor" permissions="EXECUTE"/>
  <user username="admin" password="admin" roles="admin"/>
  <user username="readonly" password="readonly" roles="read"/>
  <user username="executor" password="executor" roles="executor,read"/>
</azkaban-users>

The possible role permissions are the following:

Adjusting Properties

The main properties file azkaban.local.properties for Azkaban Servers is located in the root folder of the Web or Executor Server installation directory. Most changes to the settings in this file will not take effect until the Azkaban Web or Executor Server is restarted.

Work Directory

• Property: wherescape.job.workdir
• Description: This setting is not present by default but can be added and set to an existing directory where all the WhereScape job work files will be created. Useful in dev environments where you have multiple schedulers running on a single machine and want to avoid conflicting temporary files.
• Defaults to the following locations if the setting is not present or empty:

  • Linux defaults to /tmp

  • Windows defaults to the defined temp directory of the user (for the system user this will be C:\Windows\Temp)

Bin Directory

• Property: wherescape.red.bindir - this setting allows you to set the path that will be returned by the WSL_BINDIR environment variable in scripts.