2

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.

1 Answer 1

5

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .