A safe solution after the CVE vulnerability

[rongzeng54]

Is your feature request related to a problem? Please describe.
A safe solution after the CVE vulnerability(CVE-2020-11651 and CVE-2020-11652)

Describe the solution you'd like
In some case, salt-master cannot been complete defensed by firewall (maybe someone think firewall may also not enough, or the attack may come from a client that you trusted), at the same time the long-term automation work already built on SaltStack.

One possible solution is as follows:
server-side: Publish port is deny, return port is allowed, then the server become a server for distributing anything except command, such as state or pillar (you also need to ensure that these distribution files are trusted, but the master is no longer a God node, because it can no longer control all servers by push mode)

client-side: Send the correct salt-minion configuration and key pair by a more safely way, but make sure that your salt-minion is not started or salt-minion use different publish_port configuration(if sometimes you still need publish command from server-side, just modify or allow the publish port in server-side).

publish: Now we need salt-call work, you can do it by some tools based on SSH(pull mode, so you can publish from a credible network) or other tools based on P2P(when the network is not good, the success rate of command delivery can be improved)

Describe alternatives you've considered

• Iptables
• Black and white lists in server-side and client-side
• SaltSSH

Additional context
salt-call can run without salt-minion is running

Please Note
If this feature request would be considered a substantial change or addition, this should go through a SEP process here https://github.com/saltstack/salt-enhancement-proposals, instead of a feature request.

[cruscio]

Is this issue a request for proposals?

How about:

[1] hardening the TCP Transport so that it can be configured to complete an mTLS handshake on connection to the master? (the configuration options are there today, but I don't believe they work)

I have significant misgivings about the security of the TCP transport based on this line in transport/tcp.py:

# Always connect in plaintext; we'll convert to ssl if necessary

[2] An HTTPS WebSocket transport, with a clear separation of the creation of the WebSocket from the rest of the transport's communication. I know functionally this isn't much different from today's TCP transport, but in my experience "HTTPS WebSocket" sells a lot better to security teams. It's more familiar.

[3] An External Transport (BYO Message Bus): Configure both the master & minions to connect to a tertiary Kafka/Pulsar/RabbitMQ/Other pub/sub system. Plugable transports, just like plugable job returners.

[Skeen]

[2] An HTTPS WebSocket transport, with a clear separation of the creation of the WebSocket from the rest of the transport's communication. I know functionally this isn't much different from today's TCP transport, but in my experience "HTTPS WebSocket" sells a lot better to security teams. It's more familiar.

I was actually just considering this and considering writing a proof-of-concept HTTP transport using long-polling as a first-step.

Besides what you say, it also has the advantage of being perhaps the most common protocol there is, and as such there are a plethora of tools for debugging, routing, queueing, throttling, tracing, etc.

[cruscio]

Speaking of polling, that's how GRR works. I've considered replacing Salt with GRR in the past. My use case is highly distributed, and Salt works, but isn't well optimized for that (especially for Windows minions)

[H20-17]

I've got salt behind wireguard on all the remote minions. I set it up so whenever key is accepted an ip slot is reserverd for the PC in my inventory DB. Using external pillar data in the DB i can mark PC's as either laptops or requiring the vpn treatment. As long as they are configured before they are sent out everything should be fine.

[attritionorg]

Please incldue the CVE ID(s) being referenced.

[max-arnold]

https://hackacad.net/security/2020/05/06/how-to-secure-you-salstack-salt-master-using-spiped.html
https://gist.github.com/darkpixel/51930435c27724d2b41daa8c6bded673

Another (probably silly) idea that I'm entertaining is to embed a configurable port-knocking sequence into salt-minion source code.

[Skeen]

...

I was actually just considering this and considering writing a proof-of-concept HTTP transport using long-polling as a first-step.

I managed to implement a working HTTP transport using long-polling.
I will be creating a PR in a few days.

[lkraider]

Another option is to deploy within your own overlay network (using software like nebula or zerotier) and simply close all ports for the other network interfaces. Allows for simpler network-based security control.