1
0

index.rst 6.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180
  1. .. _sdb:
  2. ===============================
  3. Storing Data in Other Databases
  4. ===============================
  5. The SDB interface is designed to store and retrieve data that, unlike pillars
  6. and grains, is not necessarily minion-specific. The initial design goal was to
  7. allow passwords to be stored in a secure database, such as one managed by the
  8. keyring package, rather than as plain-text files. However, as a generic database
  9. interface, it could conceptually be used for a number of other purposes.
  10. SDB was added to Salt in version 2014.7.0.
  11. SDB Configuration
  12. =================
  13. In order to use the SDB interface, a configuration profile must be set up.
  14. To be available for master commands, such as runners, it needs to be
  15. configured in the master configuration. For modules executed on a minion, it
  16. can be set either in the minion configuration file, or as a pillar. The
  17. configuration stanza includes the name/ID that the profile will be referred to
  18. as, a ``driver`` setting, and any other arguments that are necessary for the SDB
  19. module that will be used. For instance, a profile called ``mykeyring``, which
  20. uses the ``system`` service in the ``keyring`` module would look like:
  21. .. code-block:: yaml
  22. mykeyring:
  23. driver: keyring
  24. service: system
  25. It is recommended to keep the name of the profile simple, as it is used in the
  26. SDB URI as well.
  27. SDB URIs
  28. ========
  29. SDB is designed to make small database queries (hence the name, SDB) using a
  30. compact URL. This allows users to reference a database value quickly inside
  31. a number of Salt configuration areas, without a lot of overhead. The basic
  32. format of an SDB URI is:
  33. .. code-block:: yaml
  34. sdb://<profile>/<args>
  35. The profile refers to the configuration profile defined in either the master or
  36. the minion configuration file. The args are specific to the module referred to
  37. in the profile, but will typically only need to refer to the key of a
  38. key/value pair inside the database. This is because the profile itself should
  39. define as many other parameters as possible.
  40. For example, a profile might be set up to reference credentials for a specific
  41. OpenStack account. The profile might look like:
  42. .. code-block:: yaml
  43. kevinopenstack:
  44. driver: keyring
  45. service: salt.cloud.openstack.kevin
  46. And the URI used to reference the password might look like:
  47. .. code-block:: yaml
  48. sdb://kevinopenstack/password
  49. Getting, Setting and Deleting SDB Values
  50. ========================================
  51. Once an SDB driver is configured, you can use the ``sdb`` execution module to
  52. get, set and delete values from it. There are two functions that may appear in
  53. most SDB modules: ``get``, ``set`` and ``delete``.
  54. Getting a value requires only the SDB URI to be specified. To retrieve a value
  55. from the ``kevinopenstack`` profile above, you would use:
  56. .. code-block:: bash
  57. salt-call sdb.get sdb://kevinopenstack/password
  58. Setting a value uses the same URI as would be used to retrieve it, followed
  59. by the value as another argument.
  60. .. code-block:: bash
  61. salt-call sdb.set 'sdb://myvault/secret/salt/saltstack' 'super awesome'
  62. Deleting values (if supported by the driver) is done pretty much the same way as
  63. getting them. Provided that you have a profile called ``mykvstore`` that uses
  64. a driver allowing to delete values you would delete a value as shown below:
  65. .. code-block:: bash
  66. salt-call sdb.delete 'sdb://mykvstore/foobar'
  67. The ``sdb.get``, ``sdb.set`` and ``sdb.delete`` functions are also available in
  68. the runner system:
  69. .. code-block:: bash
  70. salt-run sdb.get 'sdb://myvault/secret/salt/saltstack'
  71. salt-run sdb.set 'sdb://myvault/secret/salt/saltstack' 'super awesome'
  72. salt-run sdb.delete 'sdb://mykvstore/foobar'
  73. Using SDB URIs in Files
  74. =======================
  75. SDB URIs can be used in both configuration files, and files that are processed
  76. by the renderer system (jinja, mako, etc.). In a configuration file (such as
  77. ``/etc/salt/master``, ``/etc/salt/minion``, ``/etc/salt/cloud``, etc.), make an
  78. entry as usual, and set the value to the SDB URI. For instance:
  79. .. code-block:: yaml
  80. mykey: sdb://myetcd/mykey
  81. To retrieve this value using a module, the module in question must use the
  82. ``config.get`` function to retrieve configuration values. This would look
  83. something like:
  84. .. code-block:: python
  85. mykey = __salt__['config.get']('mykey')
  86. Templating renderers use a similar construct. To get the ``mykey`` value from
  87. above in Jinja, you would use:
  88. .. code-block:: jinja
  89. {{ salt['config.get']('mykey') }}
  90. When retrieving data from configuration files using ``config.get``, the SDB
  91. URI need only appear in the configuration file itself.
  92. If you would like to retrieve a key directly from SDB, you would call the
  93. ``sdb.get`` function directly, using the SDB URI. For instance, in Jinja:
  94. .. code-block:: jinja
  95. {{ salt['sdb.get']('sdb://myetcd/mykey') }}
  96. When writing Salt modules, it is not recommended to call ``sdb.get`` directly,
  97. as it requires the user to provide values in SDB, using a specific URI. Use
  98. ``config.get`` instead.
  99. .. _sdb-writing-modules:
  100. Writing SDB Modules
  101. ===================
  102. There is currently one function that MUST exist in any SDB module (``get()``),
  103. one that SHOULD exist (``set_()``) and one that MAY exist (``delete()``). If
  104. using a (``set_()``) function, a ``__func_alias__`` dictionary MUST be declared
  105. in the module as well:
  106. .. code-block:: python
  107. __func_alias__ = {
  108. 'set_': 'set',
  109. }
  110. This is because ``set`` is a Python built-in, and therefore functions should not
  111. be created which are called ``set()``. The ``__func_alias__`` functionality is
  112. provided via Salt's loader interfaces, and allows legally-named functions to be
  113. referred to using names that would otherwise be unwise to use.
  114. The ``get()`` function is required, as it will be called via functions in other
  115. areas of the code which make use of the ``sdb://`` URI. For example, the
  116. ``config.get`` function in the ``config`` execution module uses this function.
  117. The ``set_()`` function may be provided, but is not required, as some sources
  118. may be read-only, or may be otherwise unwise to access via a URI (for instance,
  119. because of SQL injection attacks).
  120. The ``delete()`` function may be provided as well, but is not required, as many
  121. sources may be read-only or restrict such operations.
  122. A simple example of an SDB module is ``salt/sdb/keyring_db.py``, as it provides
  123. basic examples of most, if not all, of the types of functionality that are
  124. available not only for SDB modules, but for Salt modules in general.