Salt权限控制

受益于灵活多样的Targeting和数以百计的Modules,Salt的远程执行功能是很强大的,在多人生产环境部署时,需要考虑两个问题:

  1. 远程执行是否只能在master上进行?
  2. 远程执行的用户权限如何控制?

在哪里执行

除了master之外,Salt Peer允许指定的minion通过master向其他minion发送指令,这个功能默认是关闭的。官网的示例如下:

peer:
  .*example.com:
    - test.*
    - ps.*
    - pkg.*
  .*foo.org:
    - test.*
    - ps.*
    - pkg.*

在对应的minion上可以通过以下命令测试:

$ salt-call publish.publish '*' test.ping

上面的配置可以看出,Peer只指定了哪些minion可以执行哪些命令,却没有限制目标minion,这也反映了Peer设计时就不是为了做master的远程执行代理的,更偏向minion与minion之间的交互,因此在考虑用户批量执行权限这块,就不用太考虑Peer了,如非特殊,所有远程操作都从master发起。

权限控制

我们准备主要测试使用external_auth权限配置。在external_auth配置前面还有个client_acl,但是感觉功能只是前者的子集,反而是client_acl_blacklist会有用一些,能够禁用一些用户(特别是root,因为其他用户都用external_auth的白名单模式管理了)或者模块(在这里禁用的模块是全局禁用,external_auth配置某些用户有权限用这些模块时,也无法使用了)。

一个测试的配置示例如下:

external_auth:
  pam:
    jasee:
      - test.* # jasee可以在所有minion上使用test模块全部命令
      - 'test-db*':
        - disk.* # 可以在ID以test-db开头的minion上使用disk模块的全部命令
      - 'G@role:web':
        - grains.* # 可以在pillar role为web的minion上使用grains和pillar模块的全部命令
        - pillar.*
    sa%:
      - '*':
        - cmd.run # sa用户组的用户可以在所有minion上使用cmd模块的run命令

重启master之后,可以通过以下命令测试:

$ salt '*' test.ping -a pam
$ salt '*' test.ping -a pam -T #同时生成一个token(~/salt_token),之后一段时间(默认12小时)不需要使用'-a pam'参数进行重复认证了。

Salt在会先进行权限检查,全部通过后才会开始命令执行。这种配置方式还是比较方便的,不知道为什么Salt不支持N@group这种Targeting方式,否则会更方便一些。
在官方的文档上,除了支持PAM认证以外还支持LDAP。不过我们是使用Kerberos进行认证,而我并没有找到相关的文档,所以只能通过PAM这种间接的方式了。
在我们的环境上(Kerberos认证+LDAP授权),按照上述配置的时候还出现了以下问题:

  1. 如果第一次使用了salt '*' test.ping -a pam -T命令,是能够执行成功并生成token的。
  2. 但是此时执行salt '*' cmd.run 'df -h',会提示认证失败,这是和我们配置的sa%部分是不相符的。
  3. 此时删除token,执行salt '*' cmd.run 'df -h' -a pam命令,能够执行成功。
  4. 此时再执行salt '*' cmd.run 'df -h' -a pam -T命令,命令失败,但是生成了token。
  5. 此时执行salt '*' test.ping,能成功执行。

因此可以看出:

  1. 当使用-T的时候,应该是认证后先生成token,再用token完成命令的授权执行。
  2. LDAP用户组在使用token的时候是无法识别的。
  3. 如果放弃使用token,Salt还是能够识别到LDAP用户组的。

不过不使用token的时候为什么能够识别到用户组呢,难道是因为此时顺带用这个用户名和密码去LDAP中查了一下?
开了TRACE级别的日志,也没有看到什么有用的信息。目前看来Salt的认证还是比较简陋的,勉强够用吧。

Loading Disqus comments...
Table of Contents