Storing files in pillar / password to certificates

[Oleg Tsarev]

Hi guys,

I investigated several sources:

https://github.com/saltstack/salt/issues/1543
https://groups.google.com/forum/#!topic/salt-users/nmVlTSHalpY

And for me still unclear, how right use pillar for storing files (for instance, private SSH/SSL keys/certificates).

I know solution with "contents: |

some data
"

But it is very useless for generate files/update file automatically.

All other solution still unclear and useless to me.

Can I support  "pillar://" syntax for clear, direct and safe way to serve files over pillar?

Another related question - does is possible to automatically enter password for SSL certificates during nginx restart?

What is the "right way" supposed for that?

I am also interesting how it would deal with machine restart (for instance) - nginx would request password on boot (not on salt startup).
I see way "disable nginx service startup" and wake up nginx + provide password over SaltStack reactor system.

Any thoughts?

Best regards, Oleg Tsarev

[Florian Ermisch]

Hi Oleg,

for getting (base64-encoded) certificates in pillar I've found the

contents: |
...
...

approach useful enough. OK, I'm not using it for private keys but the
following (snippet of a) state works fine to populate
/usr/local/share/ca-certificates on our Ubuntu-workstations:

[...]
{% for CA in salt['pillar.get']('pki:CAs',{}).keys() %}
/usr/local/share/ca-certificates/{{CA}}.crt:
file.managed:
- user: root
- group: root
- mode: 444
- contents_pillar: pki:CAs:{{CA}}
{% endfor %}
[...]

Now if you can get access to your automatically generated files by
using an ext_pillar you can get the contents of those files just like I
get the certs from pillar.


The 'password on service startup' thing might be tricky because you
don't want to pass the password as an argument to your nginx-process so
anybody with access to `ps(1)` cat get the password...

The easiest way might be by starting nginx "manually" via salt - that
is if you can get nginx to read the password from a pipe or some
similar construct (and than wrap the whole thing in a state, of
course). But at this point you know your salt-minion is already up &
running and can provide the password instead of nginx failing because
your init-system tried to start `nginx` before `salt-minion`.

I guess with those fancy new async init-systems (like systemd) you
could have nginx read the password from a named pipe so it will block
until the minion provides input to the pipe but providing the password
again when nginx needs to be restarted (and not all the time) will be
tricky. But maybe that's were you can use Salt's reactor system.

Best regards, Florian

PS: I think the "pillar://" scheme was discarded:
https://github.com/saltstack/salt/commit/3077e63