saltstack external auth
Written by: Uwe Werler onBefore 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.
-
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. ↩︎