SDB接口用于存储和检索数据，这些数据与pillars和grains不同，不一定是特定于特定minion的数据。 最初的设计目标是允许将密码存储在一个安全的数据库中，例如由keyring package管理的数据库，而不是纯文本文件。 但是，作为通用的数据库接口，它也同样可以用于许多其他管理目的。
SDB在2014.7.0版本中被添加到Salt。
要启用SDB接口，需要设置相关配置文件。 要用于master节点上的管理命令使用时（如runners程序），需要在master配置中进行配置。 对于在minion上执行的模块，可以在minion配置文件中设置，也可以作为pillar进行配置。 配置段落包括配置文件将被称为的name/ID，驱动程序设置以及将使用的SDB模块所需的任何其他参数。 例如，名为mykeyring的配置文件使用keyring模块中的system服务，如下所示：
mykeyring:
driver: keyring
service: system建议保持配置项的名称简单一些，因为它也会在SDB URI中使用。
SDB旨在使用紧凑的URL进行小型的数据库查询（因此称为SDB）。 这允许用户在多个Salt配置区域内快速引用数据库值，而不会产生大量开销。
SDB URI的基本格式是：
sdb://<profile>/<args>上面引用的<profile>是指在master或minion配置文件中定义的SDB配置项的名称。 <args>特定于配置文件中引用的模块，但通常只需要引用数据库中的key/value对的键。 这是因为应该尽可能多地在配置文件中定义各种参数。
例如，可能会将配置文件设置为引用特定OpenStack帐户的凭据。 配置文件如下所示：
kevinopenstack:
driver: keyring
service: salt.cloud.openstack.kevin用于引用密码的URI可能如下所示：
sdb://kevinopenstack/password配置SDB驱动程序后，就可以使用sdb执行模块进行获取、设置和删除值的操作了。 大多数SDB模块中都提供这几种功能：get，set和delete。
获取值只需要指定SDB URI。 要从上面的kevinopenstack配置文件中检索值，可以这样使用：
salt-call sdb.get sdb://kevinopenstack/password设置值使用与用于检索它时相同的URI，然后将值作为另一个参数。像下面这样：
salt-call sdb.set 'sdb://myvault/secret/salt/saltstack' 'super awesome'删除值（如果驱动程序支持）的方式与获取它们的方式非常相似。 如果你有一个名为mykvstore的配置文件，它使用允许删除值的驱动程序，删除一个值的操作，会像下面所示：
salt-call sdb.delete 'sdb://mykvstore/foobar'sdb.get, sdb.set 和 sdb.delete 函数同样支持在 runner 系统中使用:
salt-run sdb.get 'sdb://myvault/secret/salt/saltstack'
salt-run sdb.set 'sdb://myvault/secret/salt/saltstack' 'super awesome'
salt-run sdb.delete 'sdb://mykvstore/foobar'SDB URI可用于配置文件和由渲染器系统（jinja，mako等）处理的文件。 在配置文件（例如/etc/salt/master, /etc/salt/minion, /etc/salt/cloud, etc.）中，像往常一样创建一个条目，并将值设置为SDB URI即可。 例如：
mykey: sdb://myetcd/mykey在程序中需要通过模块检索此值，相关模块必须使用config.get函数来检索配置值。 这看起来像是这样的：
mykey = __salt__['config.get']('mykey')模板渲染器使用类似的构造。 要在Jinja中获取上面的mykey值，可以使用：
{{ salt['config.get']('mykey') }}使用config.get从配置文件中检索数据时，SDB URI只需出现在配置文件本身中。
如果你希望直接从SDB中检索密钥，则可以使用SDB URI直接调用sdb.get函数。 例如，在Jinja：
{{ salt['sdb.get']('sdb://myetcd/mykey') }}编写Salt模块时，建议不要直接调用sdb.get，因为它要求用户使用特定的URI在SDB中提供值。 请改用config.get。
目前在任何SDB模块中都必须存在一个get()函数，应该存在一个set_()，可能存在一个delete()函数。 如果使用set_()函数，则必须在模块中声明__func_alias__字典：
__func_alias__ = {
'set_': 'set',
}这是因为set是Python的内置函数，因此不能创建名为set()的函数。 __func_alias__功能是通过Salt 的loader接口提供的，并允许使用名称来引用合法命名的函数。
get()函数是必需的，因为它将通过代码的其他区域中的函数调用，这些函数使用sdb://URI。例如，config执行模块中的config.get函数使用此函数。
可以提供set_()函数，但不是必需的，因为一些源可能是只读的，或者通过URI设置可能是不明智的（例如，由于SQL注入攻击）。
也可以提供delete()函数，但不是必需的，因为许多源可能是只读的或限制这样的操作。
一个简单的SDB模块示例是salt/sdb/keyring_db.py，因为它提供了大多数（如果不是全部）功能类型的基本示例，这些功能不仅适用于SDB模块，而且适用于Salt模块。
虽然默认设置是以root用户身份运行master和minion，但有些人可能会认为以非root用户身份运行master也许可以提供额外的安全措施。 请记住，这样做并不会改变master管理minions的能力。 因此许多人认为以非root用户身份运行master不会给出任何真正的安全优势，这就是为什么master继续默认保留为root用户的原因。
注意：当master服务没有使用root用户身份运行时，某些Salt的操作会无法正确执行，特别是pam exteral auth系统，因为此系统需要root访问权来检查身份验证。
从Salt 0.9.10开始，可以以非root用户身份运行Salt。 这可以通过在master配置文件中设置 user参数来完成。 配置后需要重新启动salt-master服务。
minion也拥有它自己的 user参数，但是作为非特权用户运行minion时将阻止它对用户、已安装的软件包等进行更改，除非在minion上设置恰当的访问控制（sudo等）以允许非root用户进行所需的更改。
为了允许Salt成功以非root用户身份运行，需要调整一些目录的所有权和权限，以便所需用户可以读取和写入以下目录（及其子目录，如果适用）：
- /etc/salt
- /var/cache/salt
- /var/log/salt
- /var/run/salt
使用chown调整目录的所有权配置：
# chown -R user /etc/salt /var/cache/salt /var/log/salt /var/run/salt警告：使用指定的
root_dir参数运行master或minion服务时将影响一些路径，设置选项如pki_dir，cachedir，log_file以及通常位于上述目录中的其他选项也是如此。
Salt Minion可以通过调用salt-call命令，对自己的配置状态highstate进行初始化。
$ salt-call state.apply这将使得minion主动连接master服务，并确保它处于正确的配置“状态”。
如果你希望Salt Minion定期检查master服务器，则可以使用cron运行salt-call命令：
0 0 * * * salt-call state.apply上面的cron设置，将会每天在夜里0点运行一次。
注意：使用cron执行Salt时，请记住，cron的默认PATH可能不包含Salt使用的任何脚本或命令的路径，可能需要在crontab中相应地设置PATH：
PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin
0 0 * * * salt-call state.apply