×
  

Werlis Blog

Ich hab' mein' Sach' auf Nichts gestellt. (Max Stirner)



saltstack external auth

Written by: Uwe Werler on
Tags:  #saltstack #salt-auth #eauth #ldap

Before I suggest other people solutions I usually try them at home (or in case of eg. health or nutrition topics at myself) first. As of with operating system access I don’t like to run commands directly as root if not really necessary. The same applies to Salt too. Salt is able to use external authentication like pam or ldap. Because I run everything on OpenBSD there’s of course no pam (painful auth modules) so I decided to get Salt with my OpenLDAP1 setup working. I have a straighforward setup like described in the documentation and I use a read-only query user. I placed this into the file
/etc/salt/master.d/auth-ldap.conf:

auth.ldap.server: ldap.my.domain
auth.ldap.port: 389
auth.ldap.tls: False
auth.ldap.starttls: True
auth.ldap.scope: 2
auth.ldap.no_verify: False
auth.ldap.anonymous: False
auth.ldap.auth_by_group_membership_only: False
auth.ldap.groupou: ''
auth.ldap.groupclass: 'posixGroup'
auth.ldap.accountattributename: 'memberUid'
auth.ldap.activedirectory: False
auth.ldap.persontype: 'person'
auth.ldap.minion_stripdomains: []
auth.ldap.freeipa: False
auth.ldap.basedn: dc=my,dc=domain
auth.ldap.filter: uid={{ username  }}
auth.ldap.binddn: cn=query,ou=sys,dc=my,dc=domain
auth.ldap.bindpw: somenicepassword

Now I can authenticate with my user account stored in ldap against salt. But I need also access to certain salt commands so I created /etc/salt/master.d/acl.conf based on group membership in ldap:

external_auth:
  ldap:
    salt%:
      - '.*'
      - '@wheel'   # to allow access to all wheel modules
      - '@runner'  # to allow access to all runner modules
      - '@jobs'    # to allow access to the jobs runner and/or wheel module

Because I’m lazy I created the file ~/.saltrc:

username: uwe				# --username=uwe
#ipc_mode: tcp				# see below
eauth: ldap					# -a ldap, --auth=ldap, --eauth=ldap or --external-auth=ldap
mktoken: True				# -T/--make-token
timeout: 2					# -t 2
log_file: ~/salt.log			# avoid permission denied errors to master log

But now we run into some problems because the user has no access to the ipc sockets so the command times out:

salt:~$ salt salt.home.arpa test.ping   
[ERROR   ] Encountered StreamClosedException
[ERROR   ] 
Salt request timed out. The master is not responding. You may need to run your
command with `--async` in order to bypass the congested event bus. With
`--async`, the CLI tool will print the job id (jid) and exit immediately
without listening for responses. You can then use `salt-run jobs.lookup_jid` to
look up the results of the job in the job cache later.

To work around that we have to set in master config (eg. /etc/salt/master.d/master.conf):

ipc_mode: tcp

And now you can use “ipc_mode: tcp” also in ~/.saltrc and everything should work as expected.

Update:

On OpenBSD salt per default runs as user “_salt”. If you encounter errors like «Salt configured to run as user “_salt” but unable to switch.» the easiest way to avoid this is to deny read access to /etc/salt/master.


  1. One might ask why using an ldap server at home? It’s quite simple. I strictly separate application users like for Nextcloud or imap from users with operating system access. Because I’m lazy it’s easier to centralize these accounts in a directory service than creating always local user accounts. And most applications are able to authenticate against a ldap server but don’t support bsd auth. ↩︎