Salt Concepts

Salt introduces quite a bit of terminology and quite a few concepts.A minion is the Salt agent. Even in the agentless SSH-based communication, there is still a minion. The first thing that Salt does is send over code for a minion and then start it.

A Salt master sends commands to minions. A Salt state is a file with the .sls extension, which contains state declarations.

name_of_state:

    state.identifier:

        - parameters

        - to

        - state

For example:

process_tools:

    pkg.installed:

    - pkgs:

    - procps

This ensures the procps package (which includes the ps command among others) is installed. Most Salt states are written to be idempotent to have no effect if they are already in effect. For example, if the package is already installed, Salt does nothing.

Salt modules are different from Python modules. Internally, they do correspond to modules, but only some modules.

Unlike states, modules run things. This means that there is no guarantee, or even attempt at, idempotence. Often, a Salt state wraps a module with some logic to decide whether it needs to run the module; for example, before installing a package, pkg.installed checks if the package is already installed.

A pillar is a way of attaching parameters to specific minions, which different states can then reuse. If a pillar filters out some minions, then these minions are guaranteed to never be exposed to the values in the pillar. This means that pillars are ideal for storing secrets since they are not sent to the wrong minions.

For better protection of secrets, it is possible to use gpg to encrypt secrets in pillars. Since gpg is based on asymmetric encryption, it is possible to advertise the public key; for example, in the same source control repository that holds the states and pillars.

This means anyone can add secrets to the configuration, but the private key is needed, on the master, to apply those configurations.

Since GPG is flexible, it is possible to target the encryption to several keys. As a best practice, it is best to load the keys into a gpg-agent.

When the master needs the secrets, it uses gpg, which communicates with the gpg-agent. This means the private keys are never exposed to the Salt master directly.

In general, Salt processes directives in states in order. However, a state can always specify require. When specifying dependencies, it is best to have the dependent state have a custom, readable name. This makes dependencies more readable.