LDAP Authentication with Salt

The upcoming release of Salt 0.10.4 contains support for external authentication mechanisms. As well as restricting who can run what and on what servers, this new feature allows the handing-off of authentication to a 3rd party module.

This post describes how to setup and use an LDAP external authentication module for Salt.

Installation

Download the auth/ldap.py module from my GitHub repo and place it in the corresponding directory of your salt root (so salt/auth/ldap.py).

Configuration

Update your salt master config file to activate external authentication and set some basic ACLs:

external_auth:
  ldap:
    kris@acme.com:
      - 'saltdev':
        - test.* 

The configuration above should restrict the salt user ‘kris@acme.com’ such that he can run the ‘test’ module methods on the minion ‘saltdev’ if he successfully authenticates to LDAP.

Before this will work, however, we need to configure the LDAP connection information, also in the master config file.  This is used to make the initial LDAP bind when searching for the user dn.

As a minimum you will need:

auth.ldap.basedn:
auth.ldap.binddn:
auth.ldap.bindpw:
auth.ldap.filter: - (also see below)

NB auth.ldap.filter represents the LDAP search filter used to find the dn associated with the salt user.  It can (and normally should) contain the special string:

{{ username }}

This string (including the braces) will be substituted for the value of the username supplied by the user as part of authentication. For example the string:

auth.ldap.filter: emailAddress={{ username }}

becomes:

auth.ldap.filter: emailAddress=kris@acme.com

when a user supplies the username ‘kris@acme.com’ during authentication.

In addition, the following configuration items are as permitted:

auth.ldap.server: - default: localhost
auth.ldap.port: - default: 389 
auth.ldap.tls: - default: False 
auth.ldap.scope: - default: 2 (sub)

Usage

The salt command using external authentication looks like the following:

salt -a ldap 'saltdev' test.ping
username: kris@acme.com
password:
saltdev: True

A failed authentication attempt looks like the following:

salt -a ldap 'saltdev' test.ping
username: bob@acme.com
password:
Failed to authenticate, is this user permitted to execute commands?

To create a token which will elimiate the need to reauthenticate for a certain period (default is 12 hrs), run the same command with the -T option:

salt -T -a ldap 'saltdev' test.ping
username: kris@acme.com
password:
saltdev: True

This will create a token file called .salt_token in the user’s home directory containing the token value:

cat ~/.salt_token
02b6c56c964409c61e6806a2db2dd2e4

From this point, until the token expires, you no longer need to supply any authentication options:

salt 'saltdev' test.ping
saltdev: True

If you do run the command with the -a option, salt will ignore whatever you supply and use the token:

salt -a ldap 'saltdev' test.ping
username: foo
password: bar
saltdev: True

If you run the salt command again with the -T option, your token will be reset:

salt -T -a ldap 'saltdev' test.ping
username: kris@acme.com
password:
saltdev: True

cat /Users/kris/.salt_token
d77127794fdc7d69a9a56d

There is an implicit ‘deny all’ when you activate external authentication so only users specified in the master config will be able to access salt commands.

External authentication also supplants any client_acls specified so there should be no need to use to the two together.