Direct Targeting: Per-minion pub/sub subscription and a way to call directly #7669

Open
rmt opened this Issue Oct 8, 2013 · 4 comments

Comments

Projects
None yet
3 participants
Contributor

rmt commented Oct 8, 2013

As a security-minded user in a large environment, I would like a way to limit the broadcast scope of a remote command on the pub/sub queue to a single minion and use minion-specific encryption so that a user can send a potentially secret-revealing command to a single minion without worrying about information leakage through compromised minions.

As a bonus, I'd like to be able to send the same command using the same JobID to multiple minions via this mechanism.

Obviously this wouldn't scale as nicely as the default broadcast, which is why direct targeting isn't the default.

As a secondary bonus, I'd also like the ability to configure a minion to subscribe to an arbitrary broadcast group in addition to the default - a shared encryption key for this broadcast subscription would also be desirable.

If I've misunderstood something about how Salt distributes commands and does its encryption, please let me know and point me at the (updated if necessary) documentation.

Thanks!

Collaborator

basepi commented Oct 9, 2013

Well, Salt only broadcasts commands to the targeted minions as of 0.17.0 (it worked that way for globbing before, but not all the other targeting methods). However, I don't think it uses per-minion encryption (though I could be wrong).

This sounds like cool stuff, I've approved it for future release.

@thatch45 you might want to weigh in here.

Collaborator

basepi commented Dec 30, 2013

Just an update here: we haven't forgotten about this, and are working on a solution in tandem with partnered companies. We're not ready to announce the solution or its timeline quite yet, but we hope to get an alpha out around the next major release (not the one that's going out this month, but the next one).

Hi @basepi, I know you haven't wanted to list an ETA, but what are your thoughts on how effective this would be? I.e. would it be possible to ensure every message is encrypted with the intended minion's id?

For more context, we have an environment with different customers, and would not want one customer to be able to see the messages not intended for them (therefore revealing information about the hosts or viewing commands executed and executing them themselves (such as file copies from master to minion).

Collaborator

basepi commented Nov 24, 2014

@bradleyfalzon I haven't been very closely involved in the development of these features. I'll see if I can get more information for you.

As a side note, you might look into the syndic for your per-customer needs. Syndic masters will have a different AES session with their minions than other masters will have with their minions. So you could completely eliminate the possibility of cross-customer eavesdropping if you had a syndic per customer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment