Please support 'pillar:' URIs as source

[wwentland]

It is very common that one wants to distribute sensitive files to minions and not make that information available to all minions that are connected to the master. The only way to achieve that is to use something like:

foo:
  some_data: |
    some data
    that spans
    multiple lines

and to reference that via contents_pillar. It would be absolutely fantastic if salt would support pillar: as source and a direct mapping from those URIs to a standardised location on the filesystem (with configurable prefix, git pillar support, .... naturally). Access to the files would be controlled via a top file again and the content of the file simply becomes the value of the dictionary that is returned.

So, a location like PILLAR_FILE_ROOT/foo/bar/private_key could be accessed via pillar:///foo/bar/private_key.

Thank you!

[eliasp]

This would take so much pain out of distributing binary content, SSL/SSH keys or license files via pillars.
+1 for this!

[ssgward]

Great idea. Thanks for the input.

[florianjacob]

Just inlined a few long ssl certificates. Would be really nice to be able to keep them in the crt file and just handling them like salt:/// source files!

+1

[wwentland]

Nobody @saltstack is interested in bringing this to the community?

[arnisoph]

+111111

[srkunze]

I think the biggest reservation about this is the missing access restrictions as described here: #9569 (comment)

We basically would need to have a way to selectively choose the directories allowed to be served to a particular minion.

[wwentland]

You would naturally still need a top file in which you grant access to files to specific minions/targets.

[srkunze]

@BABILEN I would restrict this to directories as the effort to do this for all specific file might be enormous and wouldn't scale very well.

[eliasp]

Another scenario covered here I'd like to see:

• My "secret" pillar data are GPG encrypted and the GPG renderer is used to decrypt them on the master before sending them to the corresponding Minions
• I'm distributing SSL private keys

Currently, encrypting and inlining an SSL key produces a huge amount of lines within my YAML structure, which makes the YAML file rather unpleasant to manage/edit/handle.

Once distributing SSL keys etc. is doable in the way suggested here, I'd also like to be able to use GPG encrypted files which are then encrypted by the renderer first.
So something like this might work:
pillar+gpg:///foo/bar/private.key.gpg

This is a similar way other protocols (e.g. git+ssh://) are often handling such scenarios.
So the 2nd component would define the renderer to be used where the provided file has to pass through first.

[wwentland]

@eliasp, yes. That would be quite nice indeed. In fact that's a wonderful idea!

[DanyC97]

I do really need this functionality, please!
I understand the focus is more on reducing the # of bugs but please consider this feature too since many of us need to share passwords etc.

What @eliasp said is exactly what is happening in reality and guess what i have 50 different password i need to share, a gpg key for each turns the YAML into an ugly file to look at.

[jaceq]

Any update on this? I'd also love to use such feature.

[cohadar]

This is a much better alternative:
https://docs.saltstack.com/en/develop/ref/pillar/all/salt.pillar.file_tree.html#module-salt.pillar.file_tree

• deploy a file using contents_pillar with a file.managed state.

IMHO this issue should be closed.

[wwentland]

The file_tree pillar conflates targeting and data unfortunately.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.