Reason to store a SSH private key in a Salt Pillar instead of a file as part of a State

configuration-managementsaltstack

I have a set of systems (in AWS) that all need passwordless SSH access to one another. I've written a Salt state that copies a keypair (public/private SSH-RSA keys that I previously generated) and adds the appropriate entry to the user's authorized_keys file.

Right now I store the public and private keys as files in the Salt state and source them in my state definition. However, I noticed in the salt.states.file.managed() documentation that they provide an example that stores the private key in Pillar and then uses contents_pillar to get the contents of the private key.

Is there a reason I might want to store my private (or even public) key contents in Pillar instead of just a file in the state's directory? I'm not sure if there's a security advantage placing it there since the contents will end up on every system anyways. I've used Pillar for a few other things, but wasn't sure if there was a good case to use it here.

Best Answer

All states are readable from all minions, so someone (with the proper permissions) logged in any of your minion could read the private keys you store in the states.

Pillar data can be restricted to the relevant minions. This is where you store anything that is confidential to one or only some minions.

You should read the pillar documentation page: http://docs.saltstack.com/en/latest/topics/pillar/index.html

There's this note:

Storing sensitive data

Unlike state tree, pillar data is only available for the targeted minion specified by the matcher type. This makes it useful for storing sensitive data specific to a particular minion.

Related Topic