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