Minion roles

[Juan A. Moyano]

Hi There!

I was wondering, which is the preferred way to assign roles to minions? Using grains or using pillar?

Thanks!

[Alexandr Borisenko]

Hi!

We are using "nodegroups"
http://docs.saltstack.com/en/latest/topics/targeting/nodegroups.html

--
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.
For more options, visit https://groups.google.com/d/optout.

[uvs...@gmail.com]

Pillar is the right way.

Why?

* No for grains: grains are distributed. They are configured and evaluated on the minion host. When role assignment changes, do you want to go to _each_ minion (possibly restarting it) to modify roles they belong to? Or you rather change these assignments in your _centrally_ managed pillar on your master?

* No for node groups: node groups require master restart. Node groups are configured in Salt master config file. Do you want to restart master _every time_ role assignments are changed? Or you rather change these assignments in pillar and simply re-run your states?

[Colton Myers]

Couple of clarifications:

> * No for grains: grains are distributed. They are configured and evaluated on the minion host. When role assignment changes, do you want to go to _each_ minion (possibly restarting it) to modify roles they belong to? Or you rather change these assignments in your _centrally_ managed pillar on your master?

These days, you can use `grains.setval` or even sync a custom grain file from _grains/, so it no longer requires going to each minion. However, it should be noted that minions are the source of truth for grains, so if there's a security issue with a minion being able to change its own role, then you should fall back to pillar.

> * No for node groups: node groups require master restart. Node groups are configured in Salt master config file. Do you want to restart master _every time_ role assignments are changed? Or you rather change these assignments in pillar and simply re-run your states?

I don't think nodegroups require master restart anymore, but I guess I need to test again to be sure.

Both of those things said, there's no "right" answer. It really depends on your needs. But I lean towards pillar myself.

--
Colton Myers
Platform Engineer, SaltStack
@basepi on Github/Twitter/IRC

[Florian Ermisch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Colton,

Am 2. April 2015 00:00:49 MESZ, schrieb Colton Myers <colton...@gmail.com>:
>[…]

>
>I don't think nodegroups require master restart anymore, but I guess I
>need to test again to be sure.
>

Does the master now re-read its config periodically or is there a command to modify nodegroups during runtime?

Docs [0] still sound like only cmdln targeting will work w/o master restart.

Kind Regards, Florian

[0] http://docs.saltstack.com/en/latest/topics/targeting/nodegroups.html
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQFTBAEBCAA9BQJVHNlsNhxGbG9yaWFuIEVybWlzY2ggPGZsb3JpYW4uZXJtaXNj
aEBhbHVtbmkudHUtYmVybGluLmRlPgAKCRAu8tzCHoBI/UjbB/49rBYNoEzrJyYa
09FnxQ5EZo+agcZLP+co9NAdO160o35lkzOxyMAy16r7UcSml22/SKXC+8D8OUfS
G1e3np68m4y3RqXUhbsSdOY/GxkQodGKajvKVF3Kn+ovHoI1TRlAq/10XZAV74uN
EepLImN7eAKurxvheTIMBspVGwSLqB2WwuhFlSvLyMKJr53YXIUPZnjU0VMa2imi
jG2A1Z7F2Uazf4IytiXN/3PTmqzOZMUkNxstK2ApPazyKSFz2uXFKbRbRn9naxEJ
98q4PKc6c1MZQkQ7nKQOeZJlE2KXVC6YuBCXjTK7kwc5atw/nyS4/ABzcydu/qGH
EWsyHU/0
=Gqxb
-----END PGP SIGNATURE-----

[Colton Myers]

Pretty sure if you choose the nodegroup targeting type it will just read in the master config again and retrieve the nodegroups.

I haven't looked at the code to see how this is working, I just know that I tried it during a training awhile back and it worked (and I was pleasantly surprised). I guess I need to test it again to be sure, and then update the documentation.

--

Colton Myers

Platform Engineer, SaltStack

@basepi on Twitter/Github/IRC

[Andrew Hammond]

We're currently using a hybrid pillar / nodegroup approach to this. We have an inventory pillar with a roles component. The provides centralized control over which role a machine has assigned to it as well as being easy for targeting using I@inventory:roles:foo for example. But that's pretty verbose, so...

We also have nodegroups which encapsulate a number of the commonly targeted roles. This makes targeting even easier.

The problem is that we want to control access to certain pillars based on the host's role as encapsulated in a nodegroup. So... how do you reference pillars in the top.sls for the pillars... ?

Either way, salt _needs_ to have a correct answer for this problem: how do you manage roles in such a way that a compromised minion can't get access to pillar data it shouldn't. And no, listing hostnames in the pillar's top.sls is rather obviously not an acceptable solution since that would mean updating my top.sls every time I add/remove/repurpose a server... and that's not gonna scale.

This leads to another question: since we support multiple pillar roots, would it makes sense to have the top.sls for each pillar root manage the contents of those pillars? 

A

[Colton Myers]

The problem is that we want to control access to certain pillars based on the host's role as encapsulated in a nodegroup. So... how do you reference pillars in the top.sls for the pillars... ?

Unfortunately this is not possible. Chicken and egg problem.

 

Either way, salt _needs_ to have a correct answer for this problem: how do you manage roles in such a way that a compromised minion can't get access to pillar data it shouldn't. And no, listing hostnames in the pillar's top.sls is rather obviously not an acceptable solution since that would mean updating my top.sls every time I add/remove/repurpose a server... and that's not gonna scale.

This is definitely a hard problem to solve. We've thrown around ideas for making grains more secure, or securing specific grains. Many people encapsulate their minion roles in the minion ID (or hostname) of the minions, so they can use glob targeting rather than having to explicitly add each minion to the top.sls file. Since minion ID is guaranteed secure (if a minion ID were to change, the key would have to be re-accepted), this is an acceptable way to target pillar.

But you're right, we should have a method outside of minion ID, as that doesn't fit into every infrastructure.

This leads to another question: since we support multiple pillar roots, would it makes sense to have the top.sls for each pillar root manage the contents of those pillars? 

Totally up to you. You can use a single one in the base environment, or have separate ones for each. However, since top data is combine on pillar compilation, I recommend only defining top data for the environment in which the topfile is located. This will ensure there are no conflicts that could cause problems.

--

Colton Myers

Core Engineer, SaltStack

@basepi on Twitter/Github/IRC