3006 minion event bus providing too much information (similar to master event bus)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 15.7k
- Forks
- 5.6k
- Avg merge
- 2d 44m
- Merged PRs (30d)
- 80
Description
Description
I found very different behavior of minion event bus of salt-minon 3003 and 3006. In 3006 minion's event bus provides too much information and it looks pretty close to master's event bus
I revied the release notes of every single version (between versions 3003 and 3006) but could not found any information about it.
In my opinion, minion event bus should provide less data, so it can hide sensitive data (like pillar from reactor for example). This can be used for global passwords which are the same for group of minions.
Setup
I have the following example:
One state which sends event to master and listens for success event on the minion event bus - /srv/salt/test/test_request.sls:
trigger test event:
event.send:
- name: test/config/{{ grains.id }}
wait for test success event:
salt.wait_for_event:
- name: test/{{ grains.id }}/success
- timeout: 300
- id_list:
- {{ grains.id }}
- node: minion
Reactor config - /etc/salt/master.d/test_reactor.conf:
reactor:
- 'test/config/*':
- /srv/reactor/test.sls
One reactor that reacts to this event - /srv/reactor/test.sls:
#! jinja | yaml
{% import_yaml '/etc/salt/test.yaml' as test %}
test state on {{ data['id'] }}:
cmd.state.sls:
- tgt: {{ data['id'] }}
- args:
- mods: test.test
- concurrent: true
- pillar:
test: {{ test }}
One yaml with sensitive data - /etc/salt/test.yaml:
user: test
pass: testpass
And lastly one state which reactor triggers: /etc/salt/test/test.sls
test run sensitive data:
cmd.run:
- name: echo "This should be not visible on minion eventbus {{ pillar.test.user }} {{ pillar.test.pass }} "
send success event for test state:
module.run:
- event.fire:
- data: {"id":"{{ grains['id'] }}"}
- tag: test/{{ grains['id'] }}/success
- require:
- test run sensitive data
Salt master and salt-minions are running on XEN Virtual machines.
Steps to Reproduce the behavior
This should be the flow:
- Run test.test_request state, which send event to master and waits for success event on minion:
salt-call state.sls test.test_request concurrent=true
***concurrent option is if you are already listening on minion event bus - The event triggers test reactor, which imports sensitive data from /etc/salt/test.yaml
- The reactor starts test.test state on minion, which runs simple cmd.run state and success event if cmd.run succeeds
- If we receive success event the state test.test_request finishes the test.
Expected behavior
Please find the difference between both minion event bus (from command: salt-call state.event pretty=true)
salt-minion v3003:
test/test-minion-id/success {
"_stamp": "2023-10-26T12:40:31.440815",
"id": "test-minion-id"
}
salt-minion v3006:
__master_connected {
"_stamp": "2023-10-26T12:39:46.494545",
"master": "saltstack-master.test"
}
test/test-minion-id/success {
"_stamp": "2023-10-26T12:39:48.774802",
"id": "test-minion-id"
}
__master_req_channel_payload/saltstack-master.test {
"_stamp": "2023-10-26T12:39:48.787051",
"cmd": "_return",
"fun": "state.sls",
"fun_args": [
{
"concurrent": true,
"mods": "test.test",
"pillar": {
"test": {
"pass": "testpass",
"user": "test"
}
}
}
],
"id": "test-minion-id",
"jid": "20231026123841621084",
"out": "highstate",
"retcode": 0,
"return": {
"cmd_|-test run sensitive data_|-echo \"This should be not visible on minion eventbus test testpass \"_|-run": {
"__id__": "test run sensitive data",
"__run_num__": 0,
"__sls__": "test.test",
"changes": {
"pid": 3987284,
"retcode": 0,
"stderr": "",
"stdout": "This should be not visible on minion eventbus test testpass"
},
"comment": "Command \"echo \"This should be not visible on minion eventbus test testpass \"\" run",
"duration": 6.487,
"name": "echo \"This should be not visible on minion eventbus test testpass \"",
"result": true,
"start_time": "15:39:48.760840"
},
"module_|-send success event for test state_|-send success event for test state_|-run": {
"__id__": "send success event for test state",
"__run_num__": 1,
"__sls__": "test.test",
"changes": {
"event.fire": true
},
"comment": "event.fire: True",
"duration": 11.844,
"name": [
"event.fire"
],
"result": true,
"start_time": "15:39:48.768734"
}
},
"success": true,
"user": "salt"
}
Expected behavior in my opinion should be the one from salt-minion v3003.
Versions Report
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)Salt Master versions:
Salt Version:
Salt: 3006.1
Python Version:
Python: 3.10.11 (main, May 5 2023, 02:31:54) [GCC 11.2.0]
Dependency Versions:
cffi: 1.15.1
cherrypy: unknown
dateutil: 2.8.1
docker-py: Not Installed
gitdb: Not Installed
gitpython: Not Installed
Jinja2: 3.1.2
libgit2: Not Installed
looseversion: 1.0.2
M2Crypto: Not Installed
Mako: Not Installed
msgpack: 1.0.2
msgpack-pure: Not Installed
mysql-python: Not Installed
packaging: 22.0
pycparser: 2.21
pycrypto: Not Installed
pycryptodome: 3.9.8
pygit2: Not Installed
python-gnupg: 0.4.8
PyYAML: 5.4.1
PyZMQ: 23.2.0
relenv: 0.12.3
smmap: Not Installed
timelib: 0.2.4
Tornado: 4.5.3
ZMQ: 4.3.4
System Versions:
dist: ubuntu 22.04.2 jammy
locale: utf-8
machine: x86_64
release: 5.15.0-75-generic
system: Linux
version: Ubuntu 22.04.2 jammy
Salt minion 3003 version - salt-minion 3003.5
Salt minion 3006 version - salt-minion 3006.3 (Sulfur)
Additional context
Let me know if you need further information
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the report with salt-call state.sls test.test_request concurrent=true and observe the output from salt-call state.event pretty=true. Start by comparing the v3003 and v3006 minion event-bus behavior around the reactor-triggered state.sls return. Done means the minion event bus no longer exposes the sensitive pillar and command output shown in the v3006 example, while the success event still works.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- distributed-systems, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100