Salt: Peer communication with least privilege

[montao]

I would like one minion to run programs and start and stop services on another minion (Linux VMs) from the Python Salt API.
It seems like peer communication is the way to go.
https://docs.saltstack.com/en/latest/ref/peer.html
If I set a policy in the master config for a minion or a group of minion then one minion would be allowed to run programs on the other minions using the caller API in Python.

caller = salt.client.Caller()
caller.salt_call.function('publish.publish', 'host42.test.example.com', 'cmd.run', '/opt/myprogram')

My concern is that if I set the policy in the master config then the minion would be able to do anything, for example rm -rf / on any other minion and that is not very cool.

peer:
  .*.test.example.com:
    - cmd.run

Is there a way to reduce the privilege so that only a certain minion is allowed to run a specific command on a specific other minion for example host01.test.example.com is allowed to run /opt/myprogram on host42.test.example.com and no more ?

For controlling services I think that I can use the service.start instead of cmd.run but I would like both limit the privileges and be able to run custom programs for my scenario.

[Ch3LL]

There is not a way to only allow certain cmd.run commands to run. What you could do is write a custom module that runs the commands you want that minion to be able to run.

you could also limit it more by setting cmd.script instead of cmd.run but of course they could still run any script on that host.

[montao]

I think that's fine. We can make a custom module as described in the docs ( https://docs.saltstack.com/en/latest/ref/modules/index.html ) or for now I can ask the user to just start the daemon again. It's my test suite for a recovery which can make the database shutdown with the SQL SHUTDOWN statement, then run the test which should check that the database is unavailable and perform the appropriate recoveries to restore availability and then at the end I would like to reset everything back to the starting state. That is easy if someone is actually logged in at the VM and can run the daemon again. So for now that is a workaround until we automate more of it.