At some point we'll probably transition to a proper secret vaulting solution, but for now I'm taking advantage of SaltStack's GPG renderer to embed GnuPG-encryp

At some point we'll probably transition to a proper secret vaulting solution, but for now I'm taking advantage of SaltStack's GPG renderer to embed GnuPG-encrypted values into our (Git-versioned) configuration data: https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.gpg.html https://docs.saltstack.com/en/latest/ref/renderers/all/salt.... However, I often struggle to correctly format the YAML dictionaries in which I've embedded GPG-encrypted data. It is so tedious---especially when changing an encrypted value---to have to encrypt the secret, paste it into the Pillar SLS file, and carefully re-indent each line. It's especially tedious using Emacs, as a bug in yaml-mode treats the leading "---" in the GPG message start/end markers as signaling the start of a new YAML document, preventing me from highlighting the entire file and running indent-region. Fortunately, there's an easier way thanks to the Jinja renderer's import_text function. First, save the secret in a file with a name that ends in ".gpg", as Emacs' EasyPG Assistant (EPA) will transparently decrypt such a file on read and re-encrypt it on write. Second, use import_text to load the ".gpg" file into a variable. Third, reference this variable in the appropriate Pillar key like any other Jinja variable, filtering it through yaml_encode. Your Pillar SLS files go from looking like this: #!jinja|yaml|gpg a-secret: | -----BEGIN PGP MESSAGE----- Version: GnuPG v1 Base-64-encoded message text... -----END PGP MESSAGE----- To looking like this, with the added bonus that changing secrets becomes much easier: #!jinja|yaml|gpg {% import_text "a-secret.gpg" as a_secret %} a-secret: {{ a_secret|yaml_encode }} Make sure to add the armor option to "~/.gnupg/gpg.conf", otherwise import_text will throw UnicodeDecodeError exceptions.