Deploy all secret data (passwords, private keys, etc.) from `system_secrets`

uvsmtid / common-salt-states

A framework of interrelated states and pillars on top of Saltstack common to other projects.

Apache License 2.0

2 stars 0 forks source link

Deploy all secret data (passwords, private keys, etc.) from `system_secrets` #5

Closed uvsmtid closed 8 years ago

uvsmtid commented 9 years ago

At the moment only primary_user's password is configured through system_secrets.

There is also no clear procedure (and automatic support for it) how to plug in arbitrary storage (e.g. specific path on the filesystem with all secret data provided) so that Salt can use it. Adding key-values pairs through pillar has this bad encouragement that one day someone will commit the secret data into pillars repository.

Security

It is required to to provide secret pillar data to specific minions only, otherwise any minion can request anything via salt-call pillar.items.

UPDATE: It seems there is no issue to continue using Jinja templates in pillars (as long as no grains except id are used) because pillars are rendered on Salt master before being sent to minions - see this answer and this question.

uvsmtid commented 8 years ago

The secret repository can be plugged-in using configure_saly.py script and properties.yaml file.

uvsmtid commented 8 years ago

Alternatively, (instead of hiding secret data physically and recreating it on the spot) there can be two approaches.

Approach A: Sensitive data can be encrypted and committed to pillars in encrypted form as text, for example, using gpg renderer - see this link to explained use case. NOTE: It requires installation of Python libraries for GPG for Salt before 2015.8.3 (e.g. python2-gnupg package for Fedora 24).

Approach B: This way is provided by vault pillar module (which will only be available in Carbon release - not available as of 23 JUL 2016). It stores sensitive data in Vault (which encrypts persistent storage) and provides it through pillar. This way it is not maintained through source revision control in pillars (which slightly complicates things as requires more infrastructure services).

At this moment, approach A using gpg renderer seems the best choice - simpler and readily available.

uvsmtid commented 8 years ago

Commit e352055f7806129e3adc047a02bbee3efd402914 starts using pillar data encrypted using GPG (approach A).

Vault is postponed for now.

uvsmtid commented 8 years ago

Two things to note:

Once secret data is unencrypted and delivered to Salt minion as pillar value, security is effectively as strong as the way this secret data is used by Salt minion. For example, if it is written in clear text in any file without proper permissions, it can easily be stollen.
If Salt master is installed via bootstrap package, the necessary gpg setup has to be done manually - bootstrap package does not handle it at the moment. See #16.