Getting minion pillar in custom runner module

[David Anderson]

I'm just getting started playing with custom modules and runner modules...

When I allow a runner to be executed by a minion with peer_run, I know
the __opts__['id'] key will contain the calling minion id, but
everything else is in the context of the master (__grains__, etc). How
would I go about getting a dict with the pillar data of the minion?
--
Dave

[David Anderson]

I just realized it's probably recommended to do this through the
LocalClient interface using 'pillar.items'... so unless this is not the
recommended way, please disregard my post :)
--
Dave

[Colton Myers]

Yep, I think that's what you're looking for!  =)

--

Colton Myers

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[David Anderson]

After thinking about this: I'm doing a LocalClient client.cmd(minion_id,
'pillar.items', timeout=10) inside of a runner module, this is actually
executing the pillar.items module on the minion_id and having the minion
return that pillar data to the master, right?

If, somehow, someone were able to gain root on one of my minions and was
able to inject bad pillar data in the salt-minion code, the
client.cmd(pillar.items...) runner return data would also contain that
bad pillar data.

So, if the above is correct, I would like to grab the pillar data for
minion_id directly from the master in my runner module. Any other options?
--
Dave

> send an email to salt-users+...@googlegroups.com
> <mailto:salt-users%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to salt-users+...@googlegroups.com.

[Colton Myers]

So you want to make it so that one minion can get another minion's pillar from the master?

You might look into the salt mine, just have the minions cache their pillar.

That said, pillar is designed to compartmentalize data so that minions only get what they need.  Seems like making that pillar data available to other minions would be ill advised.

But I'm probably misunderstanding what you're trying to do, anyway.  =P

--

Colton Myers

    send an email to salt-users+unsubscribe@googlegroups.com

    <mailto:salt-users%2Bunsu...@googlegroups.com>.

    For more options, visit https://groups.google.com/groups/opt_out.



--
You received this message because you are subscribed to the Google Groups "Salt-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.

[David Anderson]

My goal is:

- Have a minion call a runner module via peer_run.
- The runner module gets the minion's pillar in a trusted way within
salt <-- this step is my problem
- The runner does whatever it needs to do with that data
- Runner finishes and returns whatever to the minion

--
Dave

> <mailto:da...@dubkat.com <mailto:da...@dubkat.com>>> wrote:
>
> I just realized it's probably recommended to do this
> through the
> LocalClient interface using 'pillar.items'... so unless
> this is
> not the recommended way, please disregard my post :)
> --
> Dave
>
>
> On 8/6/13 2:33 PM, David Anderson wrote:
>
> I'm just getting started playing with custom modules and
> runner modules...
>
> When I allow a runner to be executed by a minion with
> peer_run, I know the __opts__['id'] key will contain the
> calling minion id, but everything else is in the
> context of
> the master (__grains__, etc). How would I go about
> getting a
> dict with the pillar data of the minion?
> -- Dave
>
>
> -- You received this message because you are
> subscribed to the Google
> Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails
> from it,

> send an email to salt-users+...@googlegroups.com
> <mailto:salt-users%2Bunsu...@googlegroups.com>
> <mailto:salt-users%2Bunsu...@googlegroups.com
> <mailto:salt-users%252Buns...@googlegroups.com>>.

>
> For more options, visit
> https://groups.google.com/groups/opt_out.
>
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from

> it, send an email to salt-users+...@googlegroups.com

> <mailto:salt-users%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it,

> send an email to salt-users+...@googlegroups.com

> <mailto:salt-users%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Salt-users" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to salt-users+...@googlegroups.com.

[David Anderson]

After reading more of the saltstack core code, I came up with the
following function to safely get the calling minion's pillar data within
a runner module on the master. The key_from_safe_pillar() is superfluous
for a minion to actually use and is only for my testing purposes.

It works well, but it still depends on using the LocalClient to fetch
the minion's grains and the 'environment' setting from the minion config:

root@apt ~ # salt-call publish.runner
safe_pillar_test.key_from_safe_pillar 'safe_pillar_test'
does_it_work:
indeed it does

It seems like a _safe_minion_pillar function built into the salt core
and available to the master and runner modules would be super handy. Is
this is a feature only I want, or are there others out there?
--
Dave

-------------------------------------------------------
# safe_pillar_test.py
'''
Test runner for safely fetching a minion's pillar from a runner module
'''

# Import python libs
import os

# Import salt libs
import salt.client
import salt.pillar


def _safe_minion_pillar(minion_id):
'''
Safely get pillar data for the specified minion_id
'''
client = salt.client.LocalClient(__opts__['conf_file'])
minion_data = {}
minion_id = __opts__['id']
minion_data['grains'] = client.cmd(
minion_id,
'grains.items',
timeout=__opts__['timeout'])[minion_id]
minion_data['env'] = client.cmd(
minion_id,
'config.option',
['environment'],
timeout=__opts__['timeout'])[minion_id]
pillar = salt.pillar.Pillar(
__opts__,
minion_data['grains'],
minion_id,
minion_data.get('env', None),
__opts__['ext_pillar'])
minion_data['pillar'] = pillar.compile_pillar()
return minion_data['pillar']


def key_from_safe_pillar(key):
'''
Get the calling minion's pillar key from a pillar safely compiled
on the master
'''
if 'id' not in __opts__:
return None
minion_id = __opts__['id']
safe_pillar = _safe_minion_pillar(minion_id)
return safe_pillar.get(key, None)