saltstack / saltstack/salt

3006 minion event bus providing too much information (similar to master event bus)

Open
#65,470 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug needs-triage
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.