salt.example.com_master does not recieve consul_pillars when using minion targeting #38679

rbjorklin opened this Issue Jan 11, 2017 · 1 comment


None yet

2 participants


Description of Issue/Question

The special minion salt.example.com_master used during orchestration does not receive consul_pillars when using minion targeting as introduced in #37987.

I'm opening this issue because I'd like a discussion on a sensible way to solve this and be able to use orchestration and consul_pillar minion targeting together.

An easy fix would be to add and not minion_id.endswith('_master') to this line. That would however open up a potential security flaw where all minions whose name ends in _master would always receive the consul_pillar tree. Granted very few minions are likely to have their minion_id end in _master and since minion keys would have to be re-accepted if a minion_id changes in an attempt to exploit this the chances of this being a serious issue are low.

@gtmanfred gtmanfred added this to the Approved milestone Jan 17, 2017

So, unfortunately there is not a good way to do this right now as far as I am aware.

What I would look at is the __role key in opts. It can be master, minion, or syndic. Right now, the MasterMinion has minion set in that key, but you could reasonable set it to master and use that for your checking here. I think it might need to have some extra code moved around to make sure that the config file cannot overwrite the __role key as well, because I think that is currently possible.

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