1.. _pillar: 2 3================================= 4Storing Static Data in the Pillar 5================================= 6 7Pillar is an interface for Salt designed to offer global values that can be 8distributed to minions. Pillar data is managed in a similar way as 9the Salt State Tree. 10 11Pillar was added to Salt in version 0.9.8 12 13.. note:: Storing sensitive data 14 15 Pillar data is compiled on the master. Additionally, pillar data for a 16 given minion is only accessible by the minion for which it is targeted in 17 the pillar configuration. This makes pillar useful for storing sensitive 18 data specific to a particular minion. 19 20 21Declaring the Master Pillar 22=========================== 23 24The Salt Master server maintains a :conf_master:`pillar_roots` setup that 25matches the structure of the :conf_master:`file_roots` used in the Salt file 26server. Like :conf_master:`file_roots`, the :conf_master:`pillar_roots` option 27maps environments to directories. The pillar data is then mapped to minions 28based on matchers in a top file which is laid out in the same way as the state 29top file. Salt pillars can use the same matcher types as the standard :ref:`top 30file <states-top>`. 31 32conf_master:`pillar_roots` is configured just like :conf_master:`file_roots`. 33For example: 34 35.. code-block:: yaml 36 37 pillar_roots: 38 base: 39 - /srv/pillar 40 41This example configuration declares that the base environment will be located 42in the ``/srv/pillar`` directory. It must not be in a subdirectory of the 43state tree. 44 45The top file used matches the name of the top file used for States, 46and has the same structure: 47 48``/srv/pillar/top.sls`` 49 50.. code-block:: yaml 51 52 base: 53 '*': 54 - packages 55 56In the above top file, it is declared that in the ``base`` environment, the 57glob matching all minions will have the pillar data found in the ``packages`` 58pillar available to it. Assuming the ``pillar_roots`` value of ``/srv/pillar`` 59taken from above, the ``packages`` pillar would be located at 60``/srv/pillar/packages.sls``. 61 62Any number of matchers can be added to the base environment. For example, here 63is an expanded version of the Pillar top file stated above: 64 65/srv/pillar/top.sls: 66 67.. code-block:: yaml 68 69 base: 70 '*': 71 - packages 72 'web*': 73 - vim 74 75In this expanded top file, minions that match ``web*`` will have access to the 76``/srv/pillar/packages.sls`` file, as well as the ``/srv/pillar/vim.sls`` file. 77 78Another example shows how to use other standard top matching types 79to deliver specific salt pillar data to minions with different properties. 80 81Here is an example using the ``grains`` matcher to target pillars to minions 82by their ``os`` grain: 83 84.. code-block:: yaml 85 86 dev: 87 'os:Debian': 88 - match: grain 89 - servers 90 91Pillar definitions can also take a keyword argument ``ignore_missing``. 92When the value of ``ignore_missing`` is ``True``, all errors for missing 93pillar files are ignored. The default value for ``ignore_missing`` is 94``False``. 95 96Here is an example using the ``ignore_missing`` keyword parameter to ignore 97errors for missing pillar files: 98 99.. code-block:: yaml 100 101 base: 102 '*': 103 - servers 104 - systems 105 - ignore_missing: True 106 107Assuming that the pillar ``servers`` exists in the fileserver backend 108and the pillar ``systems`` doesn't, all pillar data from ``servers`` 109pillar is delivered to minions and no error for the missing pillar 110``systems`` is noted under the key ``_errors`` in the pillar data 111delivered to minions. 112 113Should the ``ignore_missing`` keyword parameter have the value ``False``, 114an error for the missing pillar ``systems`` would produce the value 115``Specified SLS 'servers' in environment 'base' is not available on the salt master`` 116under the key ``_errors`` in the pillar data delivered to minions. 117 118``/srv/pillar/packages.sls`` 119 120.. code-block:: jinja 121 122 {% if grains['os'] == 'RedHat' %} 123 apache: httpd 124 git: git 125 {% elif grains['os'] == 'Debian' %} 126 apache: apache2 127 git: git-core 128 {% endif %} 129 130 company: Foo Industries 131 132.. important:: 133 See :ref:`Is Targeting using Grain Data Secure? <faq-grain-security>` for 134 important security information. 135 136The above pillar sets two key/value pairs. If a minion is running RedHat, then 137the ``apache`` key is set to ``httpd`` and the ``git`` key is set to the value 138of ``git``. If the minion is running Debian, those values are changed to 139``apache2`` and ``git-core`` respectively. All minions that have this pillar 140targeting to them via a top file will have the key of ``company`` with a value 141of ``Foo Industries``. 142 143Consequently this data can be used from within modules, renderers, State SLS 144files, and more via the shared pillar dictionary: 145 146.. code-block:: jinja 147 148 apache: 149 pkg.installed: 150 - name: {{ pillar['apache'] }} 151 152.. code-block:: jinja 153 154 git: 155 pkg.installed: 156 - name: {{ pillar['git'] }} 157 158Finally, the above states can utilize the values provided to them via Pillar. 159All pillar values targeted to a minion are available via the 'pillar' 160dictionary. As seen in the above example, Jinja substitution can then be 161utilized to access the keys and values in the Pillar dictionary. 162 163Note that you cannot just list key/value-information in ``top.sls``. Instead, 164target a minion to a pillar file and then list the keys and values in the 165pillar. Here is an example top file that illustrates this point: 166 167.. code-block:: yaml 168 169 base: 170 '*': 171 - common_pillar 172 173And the actual pillar file at '/srv/pillar/common_pillar.sls': 174 175.. code-block:: yaml 176 177 foo: bar 178 boo: baz 179 180.. note:: 181 When working with multiple pillar environments, assuming that each pillar 182 environment has its own top file, the jinja placeholder ``{{ saltenv }}`` 183 can be used in place of the environment name: 184 185 .. code-block:: jinja 186 187 {{ saltenv }}: 188 '*': 189 - common_pillar 190 191 Yes, this is ``{{ saltenv }}``, and not ``{{ pillarenv }}``. The reason for 192 this is because the Pillar top files are parsed using some of the same code 193 which parses top files when :ref:`running states <running-highstate>`, so 194 the pillar environment takes the place of ``{{ saltenv }}`` in the jinja 195 context. 196 197 198Dynamic Pillar Environments 199=========================== 200 201If environment ``__env__`` is specified in :conf_master:`pillar_roots`, all 202environments that are not explicitly specified in :conf_master:`pillar_roots` 203will map to the directories from ``__env__``. This allows one to use dynamic 204git branch based environments for state/pillar files with the same file-based 205pillar applying to all environments. For example: 206 207.. code-block:: yaml 208 209 pillar_roots: 210 __env__: 211 - /srv/pillar 212 213 ext_pillar: 214 - git: 215 - __env__ https://example.com/git-pillar.git 216 217.. versionadded:: 2017.7.5,2018.3.1 218 219 220Pillar Namespace Flattening 221=========================== 222 223The separate pillar SLS files all merge down into a single dictionary of 224key-value pairs. When the same key is defined in multiple SLS files, this can 225result in unexpected behavior if care is not taken to how the pillar SLS files 226are laid out. 227 228For example, given a ``top.sls`` containing the following: 229 230.. code-block:: yaml 231 232 base: 233 '*': 234 - packages 235 - services 236 237with ``packages.sls`` containing: 238 239.. code-block:: yaml 240 241 bind: bind9 242 243and ``services.sls`` containing: 244 245.. code-block:: yaml 246 247 bind: named 248 249Then a request for the ``bind`` pillar key will only return ``named``. The 250``bind9`` value will be lost, because ``services.sls`` was evaluated later. 251 252.. note:: 253 Pillar files are applied in the order they are listed in the top file. 254 Therefore conflicting keys will be overwritten in a 'last one wins' manner! 255 For example, in the above scenario conflicting key values in ``services`` 256 will overwrite those in ``packages`` because it's at the bottom of the list. 257 258It can be better to structure your pillar files with more hierarchy. For 259example the ``package.sls`` file could be configured like so: 260 261.. code-block:: yaml 262 263 packages: 264 bind: bind9 265 266This would make the ``packages`` pillar key a nested dictionary containing a 267``bind`` key. 268 269Pillar Dictionary Merging 270========================= 271 272If the same pillar key is defined in multiple pillar SLS files, and the keys in 273both files refer to nested dictionaries, then the content from these 274dictionaries will be recursively merged. 275 276For example, keeping the ``top.sls`` the same, assume the following 277modifications to the pillar SLS files: 278 279``packages.sls``: 280 281.. code-block:: yaml 282 283 bind: 284 package-name: bind9 285 version: 9.9.5 286 287``services.sls``: 288 289.. code-block:: yaml 290 291 bind: 292 port: 53 293 listen-on: any 294 295The resulting pillar dictionary will be: 296 297.. code-block:: bash 298 299 $ salt-call pillar.get bind 300 local: 301 ---------- 302 listen-on: 303 any 304 package-name: 305 bind9 306 port: 307 53 308 version: 309 9.9.5 310 311Since both pillar SLS files contained a ``bind`` key which contained a nested 312dictionary, the pillar dictionary's ``bind`` key contains the combined contents 313of both SLS files' ``bind`` keys. 314 315.. _pillar-include: 316 317Including Other Pillars 318======================= 319 320.. versionadded:: 0.16.0 321 322Pillar SLS files may include other pillar files, similar to State files. Two 323syntaxes are available for this purpose. The simple form simply includes the 324additional pillar as if it were part of the same file: 325 326.. code-block:: yaml 327 328 include: 329 - users 330 331The full include form allows two additional options -- passing default values 332to the templating engine for the included pillar file as well as an optional 333key under which to nest the results of the included pillar: 334 335.. code-block:: yaml 336 337 include: 338 - users: 339 defaults: 340 sudo: ['bob', 'paul'] 341 key: users 342 343With this form, the included file (users.sls) will be nested within the 'users' 344key of the compiled pillar. Additionally, the 'sudo' value will be available 345as a template variable to users.sls. 346 347.. _pillar-in-memory: 348 349In-Memory Pillar Data vs. On-Demand Pillar Data 350=============================================== 351 352Since compiling pillar data is computationally expensive, the minion will 353maintain a copy of the pillar data in memory to avoid needing to ask the master 354to recompile and send it a copy of the pillar data each time pillar data is 355requested. This in-memory pillar data is what is returned by the 356:py:func:`pillar.item <salt.modules.pillar.item>`, :py:func:`pillar.get 357<salt.modules.pillar.get>`, and :py:func:`pillar.raw <salt.modules.pillar.raw>` 358functions. 359 360Also, for those writing custom execution modules, or contributing to Salt's 361existing execution modules, the in-memory pillar data is available as the 362``__pillar__`` dunder dictionary. 363 364The in-memory pillar data is generated on minion start, and can be refreshed 365using the :py:func:`saltutil.refresh_pillar 366<salt.modules.saltutil.refresh_pillar>` function: 367 368.. code-block:: bash 369 370 salt '*' saltutil.refresh_pillar 371 372This function triggers the minion to asynchronously refresh the in-memory 373pillar data and will always return ``None``. 374 375In contrast to in-memory pillar data, certain actions trigger pillar data to be 376compiled to ensure that the most up-to-date pillar data is available. These 377actions include: 378 379- Running states 380- Running :py:func:`pillar.items <salt.modules.pillar.items>` 381 382Performing these actions will *not* refresh the in-memory pillar data. So, if 383pillar data is modified, and then states are run, the states will see the 384updated pillar data, but :py:func:`pillar.item <salt.modules.pillar.item>`, 385:py:func:`pillar.get <salt.modules.pillar.get>`, and :py:func:`pillar.raw 386<salt.modules.pillar.raw>` will not see this data unless refreshed using 387:py:func:`saltutil.refresh_pillar <salt.modules.saltutil.refresh_pillar>`. 388 389.. _pillar-environments: 390 391How Pillar Environments Are Handled 392=================================== 393 394When multiple pillar environments are used, the default behavior is for the 395pillar data from all environments to be merged together. The pillar dictionary 396will therefore contain keys from all configured environments. 397 398The :conf_minion:`pillarenv` minion config option can be used to force the 399minion to only consider pillar configuration from a single environment. This 400can be useful in cases where one needs to run states with alternate pillar 401data, either in a testing/QA environment or to test changes to the pillar data 402before pushing them live. 403 404For example, assume that the following is set in the minion config file: 405 406.. code-block:: yaml 407 408 pillarenv: base 409 410This would cause that minion to ignore all other pillar environments besides 411``base`` when compiling the in-memory pillar data. Then, when running states, 412the ``pillarenv`` CLI argument can be used to override the minion's 413:conf_minion:`pillarenv` config value: 414 415.. code-block:: bash 416 417 salt '*' state.apply mystates pillarenv=testing 418 419The above command will run the states with pillar data sourced exclusively from 420the ``testing`` environment, without modifying the in-memory pillar data. 421 422.. note:: 423 When running states, the ``pillarenv`` CLI option does not require a 424 :conf_minion:`pillarenv` option to be set in the minion config file. When 425 :conf_minion:`pillarenv` is left unset, as mentioned above all configured 426 environments will be combined. Running states with ``pillarenv=testing`` in 427 this case would still restrict the states' pillar data to just that of the 428 ``testing`` pillar environment. 429 430Starting in the 2017.7.0 release, it is possible to pin the pillarenv to the 431effective saltenv, using the :conf_minion:`pillarenv_from_saltenv` minion 432config option. When this is set to ``True``, if a specific saltenv is specified 433when running states, the ``pillarenv`` will be the same. This essentially makes 434the following two commands equivalent: 435 436.. code-block:: bash 437 438 salt '*' state.apply mystates saltenv=dev 439 salt '*' state.apply mystates saltenv=dev pillarenv=dev 440 441However, if a pillarenv is specified, it will override this behavior. So, the 442following command will use the ``qa`` pillar environment but source the SLS 443files from the ``dev`` saltenv: 444 445.. code-block:: bash 446 447 salt '*' state.apply mystates saltenv=dev pillarenv=qa 448 449So, if a ``pillarenv`` is set in the minion config file, 450:conf_minion:`pillarenv_from_saltenv` will be ignored, and passing a 451``pillarenv`` on the CLI will temporarily override 452:conf_minion:`pillarenv_from_saltenv`. 453 454 455Viewing Pillar Data 456=================== 457 458To view pillar data, use the :mod:`pillar <salt.modules.pillar>` execution 459module. This module includes several functions, each of them with their own 460use. These functions include: 461 462- :py:func:`pillar.item <salt.modules.pillar.item>` - Retrieves the value of 463 one or more keys from the :ref:`in-memory pillar data <pillar-in-memory>`. 464- :py:func:`pillar.items <salt.modules.pillar.items>` - Compiles a fresh pillar 465 dictionary and returns it, leaving the :ref:`in-memory pillar data 466 <pillar-in-memory>` untouched. If pillar keys are passed to this function 467 however, this function acts like :py:func:`pillar.item 468 <salt.modules.pillar.item>` and returns their values from the :ref:`in-memory 469 pillar data <pillar-in-memory>`. 470- :py:func:`pillar.raw <salt.modules.pillar.raw>` - Like :py:func:`pillar.items 471 <salt.modules.pillar.items>`, it returns the entire pillar dictionary, but 472 from the :ref:`in-memory pillar data <pillar-in-memory>` instead of compiling 473 fresh pillar data. 474- :py:func:`pillar.get <salt.modules.pillar.get>` - Described in detail below. 475 476 477The :py:func:`pillar.get <salt.modules.pillar.get>` Function 478============================================================ 479 480.. versionadded:: 0.14.0 481 482The :mod:`pillar.get <salt.modules.pillar.get>` function works much in the same 483way as the ``get`` method in a python dict, but with an enhancement: nested 484dictonaries can be traversed using a colon as a delimiter. 485 486If a structure like this is in pillar: 487 488.. code-block:: yaml 489 490 foo: 491 bar: 492 baz: qux 493 494Extracting it from the raw pillar in an sls formula or file template is done 495this way: 496 497.. code-block:: jinja 498 499 {{ pillar['foo']['bar']['baz'] }} 500 501Now, with the new :mod:`pillar.get <salt.modules.pillar.get>` function the data 502can be safely gathered and a default can be set, allowing the template to fall 503back if the value is not available: 504 505.. code-block:: jinja 506 507 {{ salt['pillar.get']('foo:bar:baz', 'qux') }} 508 509This makes handling nested structures much easier. 510 511.. note:: ``pillar.get()`` vs ``salt['pillar.get']()`` 512 513 It should be noted that within templating, the ``pillar`` variable is just 514 a dictionary. This means that calling ``pillar.get()`` inside of a 515 template will just use the default dictionary ``.get()`` function which 516 does not include the extra ``:`` delimiter functionality. It must be 517 called using the above syntax (``salt['pillar.get']('foo:bar:baz', 518 'qux')``) to get the salt function, instead of the default dictionary 519 behavior. 520 521Setting Pillar Data at the Command Line 522======================================= 523 524Pillar data can be set at the command line like the following example: 525 526.. code-block:: bash 527 528 salt '*' state.apply pillar='{"cheese": "spam"}' 529 530This will add a pillar key of ``cheese`` with its value set to ``spam``. 531 532.. note:: 533 534 Be aware that when sending sensitive data via pillar on the command-line 535 that the publication containing that data will be received by all minions 536 and will not be restricted to the targeted minions. This may represent 537 a security concern in some cases. 538 539.. _pillar-encryption: 540 541Pillar Encryption 542================= 543 544Salt's renderer system can be used to decrypt pillar data. This allows for 545pillar items to be stored in an encrypted state, and decrypted during pillar 546compilation. 547 548Encrypted Pillar SLS 549-------------------- 550 551.. versionadded:: 2017.7.0 552 553Consider the following pillar SLS file: 554 555.. code-block:: yaml 556 557 secrets: 558 vault: 559 foo: | 560 -----BEGIN PGP MESSAGE----- 561 562 hQEMAw2B674HRhwSAQgAhTrN8NizwUv/VunVrqa4/X8t6EUulrnhKcSeb8sZS4th 563 W1Qz3K2NjL4lkUHCQHKZVx/VoZY7zsddBIFvvoGGfj8+2wjkEDwFmFjGE4DEsS74 564 ZLRFIFJC1iB/O0AiQ+oU745skQkU6OEKxqavmKMrKo3rvJ8ZCXDC470+i2/Hqrp7 565 +KWGmaDOO422JaSKRm5D9bQZr9oX7KqnrPG9I1+UbJyQSJdsdtquPWmeIpamEVHb 566 VMDNQRjSezZ1yKC4kCWm3YQbBF76qTHzG1VlLF5qOzuGI9VkyvlMaLfMibriqY73 567 zBbPzf6Bkp2+Y9qyzuveYMmwS4sEOuZL/PetqisWe9JGAWD/O+slQ2KRu9hNww06 568 KMDPJRdyj5bRuBVE4hHkkP23KrYr7SuhW2vpe7O/MvWEJ9uDNegpMLhTWruGngJh 569 iFndxegN9w== 570 =bAuo 571 -----END PGP MESSAGE----- 572 bar: this was unencrypted already 573 baz: | 574 -----BEGIN PGP MESSAGE----- 575 576 hQEMAw2B674HRhwSAQf+Ne+IfsP2IcPDrUWct8sTJrga47jQvlPCmO+7zJjOVcqz 577 gLjUKvMajrbI/jorBWxyAbF+5E7WdG9WHHVnuoywsyTB9rbmzuPqYCJCe+ZVyqWf 578 9qgJ+oUjcvYIFmH3h7H68ldqbxaAUkAOQbTRHdr253wwaTIC91ZeX0SCj64HfTg7 579 Izwk383CRWonEktXJpientApQFSUWNeLUWagEr/YPNFA3vzpPF5/Ia9X8/z/6oO2 580 q+D5W5mVsns3i2HHbg2A8Y+pm4TWnH6mTSh/gdxPqssi9qIrzGQ6H1tEoFFOEq1V 581 kJBe0izlfudqMq62XswzuRB4CYT5Iqw1c97T+1RqENJCASG0Wz8AGhinTdlU5iQl 582 JkLKqBxcBz4L70LYWyHhYwYROJWjHgKAywX5T67ftq0wi8APuZl9olnOkwSK+wrY 583 1OZi 584 =7epf 585 -----END PGP MESSAGE----- 586 qux: 587 - foo 588 - bar 589 - | 590 -----BEGIN PGP MESSAGE----- 591 592 hQEMAw2B674HRhwSAQgAg1YCmokrweoOI1c9HO0BLamWBaFPTMblOaTo0WJLZoTS 593 ksbQ3OJAMkrkn3BnnM/djJc5C7vNs86ZfSJ+pvE8Sp1Rhtuxh25EKMqGOn/SBedI 594 gR6N5vGUNiIpG5Tf3DuYAMNFDUqw8uY0MyDJI+ZW3o3xrMUABzTH0ew+Piz85FDA 595 YrVgwZfqyL+9OQuu6T66jOIdwQNRX2NPFZqvon8liZUPus5VzD8E5cAL9OPxQ3sF 596 f7/zE91YIXUTimrv3L7eCgU1dSxKhhfvA2bEUi+AskMWFXFuETYVrIhFJAKnkFmE 597 uZx+O9R9hADW3hM5hWHKH9/CRtb0/cC84I9oCWIQPdI+AaPtICxtsD2N8Q98hhhd 598 4M7I0sLZhV+4ZJqzpUsOnSpaGyfh1Zy/1d3ijJi99/l+uVHuvmMllsNmgR+ZTj0= 599 =LrCQ 600 -----END PGP MESSAGE----- 601 602When the pillar data is compiled, the results will be decrypted: 603 604.. code-block:: bash 605 606 # salt myminion pillar.items 607 myminion: 608 ---------- 609 secrets: 610 ---------- 611 vault: 612 ---------- 613 bar: 614 this was unencrypted already 615 baz: 616 rosebud 617 foo: 618 supersecret 619 qux: 620 - foo 621 - bar 622 - baz 623 624Salt must be told what portions of the pillar data to decrypt. This is done 625using the :conf_master:`decrypt_pillar` config option: 626 627.. code-block:: yaml 628 629 decrypt_pillar: 630 - 'secrets:vault': gpg 631 632The notation used to specify the pillar item(s) to be decrypted is the same as 633the one used in :py:func:`pillar.get <salt.modules.pillar.get>` function. 634 635If a different delimiter is needed, it can be specified using the 636:conf_master:`decrypt_pillar_delimiter` config option: 637 638.. code-block:: yaml 639 640 decrypt_pillar: 641 - 'secrets|vault': gpg 642 643 decrypt_pillar_delimiter: '|' 644 645The name of the renderer used to decrypt a given pillar item can be omitted, 646and if so it will fall back to the value specified by the 647:conf_master:`decrypt_pillar_default` config option, which defaults to ``gpg``. 648So, the first example above could be rewritten as: 649 650.. code-block:: yaml 651 652 decrypt_pillar: 653 - 'secrets:vault' 654 655Encrypted Pillar Data on the CLI 656-------------------------------- 657 658.. versionadded:: 2016.3.0 659 660The following functions support passing pillar data on the CLI via the 661``pillar`` argument: 662 663- :py:func:`pillar.items <salt.modules.pillar.items>` 664- :py:func:`state.apply <salt.modules.state.apply_>` 665- :py:func:`state.highstate <salt.modules.state.highstate>` 666- :py:func:`state.sls <salt.modules.state.sls>` 667 668Triggerring decryption of this CLI pillar data can be done in one of two ways: 669 6701. Using the ``pillar_enc`` argument: 671 672 .. code-block:: bash 673 674 # salt myminion pillar.items pillar_enc=gpg pillar='{foo: "-----BEGIN PGP MESSAGE-----\n\nhQEMAw2B674HRhwSAQf+OvPqEdDoA2fk15I5dYUTDoj1yf/pVolAma6iU4v8Zixn\nRDgWsaAnFz99FEiFACsAGDEFdZaVOxG80T0Lj+PnW4pVy0OXmXHnY2KjV9zx8FLS\nQxfvmhRR4t23WSFybozfMm0lsN8r1vfBBjbK+A72l0oxN78d1rybJ6PWNZiXi+aC\nmqIeunIbAKQ21w/OvZHhxH7cnIiGQIHc7N9nQH7ibyoKQzQMSZeilSMGr2abAHun\nmLzscr4wKMb+81Z0/fdBfP6g3bLWMJga3hSzSldU9ovu7KR8rDJI1qOlENj3Wm8C\nwTpDOB33kWIKMqiAjY3JFtb5MCHrafyggwQL7cX1+tI+AbSO6kZpbcDfzetb77LZ\nxc5NWnnGK4pGoqq4MAmZshw98RpecSHKMosto2gtiuWCuo9Zn5cV/FbjZ9CTWrQ=\n=0hO/\n-----END PGP MESSAGE-----"}' 675 676 The newlines in this example are specified using a literal ``\n``. Newlines 677 can be replaced with a literal ``\n`` using ``sed``: 678 679 .. code-block:: bash 680 681 $ echo -n bar | gpg --armor --trust-model always --encrypt -r user@domain.tld | sed ':a;N;$!ba;s/\n/\\n/g' 682 683 .. note:: 684 Using ``pillar_enc`` will perform the decryption minion-side, so for 685 this to work it will be necessary to set up the keyring in 686 ``/etc/salt/gpgkeys`` on the minion just as one would typically do on 687 the master. The easiest way to do this is to first export the keys from 688 the master: 689 690 .. code-block:: bash 691 692 # gpg --homedir /etc/salt/gpgkeys --export-secret-key -a user@domain.tld >/tmp/keypair.gpg 693 694 Then, copy the file to the minion, setup the keyring, and import: 695 696 .. code-block:: bash 697 698 # mkdir -p /etc/salt/gpgkeys 699 # chmod 0700 /etc/salt/gpgkeys 700 # gpg --homedir /etc/salt/gpgkeys --list-keys 701 # gpg --homedir /etc/salt/gpgkeys --import --allow-secret-key-import keypair.gpg 702 703 The ``--list-keys`` command is run create a keyring in the newly-created 704 directory. 705 706 Pillar data which is decrypted minion-side will still be securely 707 transferred to the master, since the data sent between minion and master is 708 encrypted with the master's public key. 709 7102. Use the :conf_master:`decrypt_pillar` option. This is less flexible in that 711 the pillar key passed on the CLI must be pre-configured on the master, but 712 it doesn't require a keyring to be setup on the minion. One other caveat to 713 this method is that pillar decryption on the master happens at the end of 714 pillar compilation, so if the encrypted pillar data being passed on the CLI 715 needs to be referenced by pillar or ext_pillar *during pillar compilation*, 716 it *must* be decrypted minion-side. 717 718 719Adding New Renderers for Decryption 720----------------------------------- 721 722Those looking to add new renderers for decryption should look at the :mod:`gpg 723<salt.renderers.gpg>` renderer for an example of how to do so. The function 724that performs the decryption should be recursive and be able to traverse a 725mutable type such as a dictionary, and modify the values in-place. 726 727Once the renderer has been written, :conf_master:`decrypt_pillar_renderers` 728should be modified so that Salt allows it to be used for decryption. 729 730If the renderer is being submitted upstream to the Salt project, the renderer 731should be added in `salt/renderers/`_. Additionally, the following should be 732done: 733 734- Both occurrences of :conf_master:`decrypt_pillar_renderers` in 735 `salt/config/__init__.py`_ should be updated to include the name of the new 736 renderer so that it is included in the default value for this config option. 737- The documentation for the :conf_master:`decrypt_pillar_renderers` config 738 option in the `master config file`_ and `minion config file`_ should be 739 updated to show the correct new default value. 740- The commented example for the :conf_master:`decrypt_pillar_renderers` config 741 option in the `master config template`_ should be updated to show the correct 742 new default value. 743 744.. _`salt/renderers/`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/renderers/ 745.. _`salt/config/__init__.py`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/salt/config/__init__.py 746.. _`master config file`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/doc/ref/configuration/master.rst 747.. _`minion config file`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/doc/ref/configuration/minion.rst 748.. _`master config template`: https://github.com/saltstack/salt/tree/|repo_primary_branch|/conf/master 749 750Binary Data in the Pillar 751========================= 752 753Salt has partial support for binary pillar data. 754 755.. note:: 756 757 There are some situations (such as salt-ssh) where only text (ASCII or 758 Unicode) is allowed. 759 760The simplest way to embed binary data in your pillar is to make use of YAML's 761built-in binary data type, which requires base64 encoded data. 762 763.. code-block:: yaml 764 765 salt_pic: !!binary 766 iVBORw0KGgoAAAANSUhEUgAAAAoAAAAKCAMAAAC67D+PAAAABGdBTUEAALGPC/xhBQAAACBjSFJNAA 767 768Then you can use it as a ``contents_pillar`` in a state: 769 770.. code-block:: yaml 771 772 /tmp/salt.png: 773 file.managed: 774 - contents_pillar: salt_pic 775 776It is also possible to add ASCII-armored encrypted data to pillars, as 777mentioned in the Pillar Encryption section. 778 779Master Config in Pillar 780======================= 781 782For convenience the data stored in the master configuration file can be made 783available in all minion's pillars. This makes global configuration of services 784and systems very easy but may not be desired if sensitive data is stored in the 785master configuration. This option is disabled by default. 786 787To enable the master config from being added to the pillar set 788:conf_minion:`pillar_opts` to ``True`` in the minion config file: 789 790.. code-block:: yaml 791 792 pillar_opts: True 793 794Minion Config in Pillar 795======================= 796 797Minion configuration options can be set on pillars. Any option that you want 798to modify, should be in the first level of the pillars, in the same way you set 799the options in the config file. For example, to configure the MySQL root 800password to be used by MySQL Salt execution module, set the following pillar 801variable: 802 803.. code-block:: yaml 804 805 mysql.pass: hardtoguesspassword 806 807 808Master Provided Pillar Error 809============================ 810 811By default if there is an error rendering a pillar, the detailed error is 812hidden and replaced with: 813 814.. code-block:: bash 815 816 Rendering SLS 'my.sls' failed. Please see master log for details. 817 818The error is protected because it's possible to contain templating data 819which would give that minion information it shouldn't know, like a password! 820 821To have the master provide the detailed error that could potentially carry 822protected data set ``pillar_safe_render_error`` to ``False``: 823 824.. code-block:: yaml 825 826 pillar_safe_render_error: False 827 828.. toctree:: 829 ../tutorials/pillar 830