1

Consider two approaches to distribute selected pillar keys to specific minion.

1. Top-file matcher using minion id.

In this case, top file has to know assignments of pillar sls files to their minions.

/srv/pillar/top.sls:

base:
  'minion_1':
    - key1
  'minion_2':
    - key2

/srv/pillar/key1.sls:

key1: value1

/srv/pillar/key2.sls:

key2: value2

2. Jinja conditional using if/else with minion id.

In this case, top file need to know nothing.

Instead, pillar sls files know themselves which minion can read them.

/srv/pillar/top.sls:

base:
  '*':
    - key1
    - key2

/srv/pillar/key1.sls:

{% if grains['id'] == 'minion_1' %}
key1: value1
{% endif %}

/srv/pillar/key2.sls:

{% if grains['id'] == 'minion_2' %}
key2: value2
{% endif %}

Question

Are there any security preferences using the 1st or the 2nd approach?

Personally, I prefer the 2nd approach - it is more flexible (allows any logic in jinja templates).

While writing this I also clarified an important Salt design aspect - pillar sls files are only compiled on Salt master in either cases (see this answer). Therefore, in both cases minions will never be given all pillar data anyway (to filter, select, and present resulted pillar for state rendering on their own). Compare it with states - AFAIK, they are rendered on minon side.

Community
  • 1
  • 1
uvsmtid
  • 4,187
  • 4
  • 38
  • 64

2 Answers2

1

IMHO either of those approaches look pretty much the same from a security perspective.

As you say, each salt-minion only sees the pillar data that the salt-master allows it to see.

The 1st approach looks more straightforward, and the grains are supplied by the minions - so if you've got a hacked minion it could see stuff that it shouldn't be able to ......

A bigger security risk is having un-encrypted keys etc hanging around in your pillars (especially if you're sharing them in a git or whatever). Have you seen this? https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.gpg.html, gpg encryption for your pillars.

Been using it for about 4 months without issue.

Ian Ellis
  • 389
  • 3
  • 8
  • Yes. I'm also in favour of `gpg` renderer - it enables storing even sensitive data in Git. Setting key filter for `gpg`-encrypted values was actually the moment when I realized it is better to be able to filter specific pillar keys per minion to avoid exposing unencrypted secret values to all minions. – uvsmtid Jul 23 '16 at 18:59
0

You should NOT use the second approach.

Remember, that grains are insecure and any minion can present itself as having any grain. Evaluating a grain in Jinja, especially to determine access to pillar data effectively bypasses Salt's security model.

Michael Place
  • 2,986
  • 1
  • 19
  • 18
  • is it also true for minion **`id`** grain? What I understood via some discussions and **[official section in Salt docs](https://docs.saltstack.com/en/latest/faq.html#faq-grain-security)** is that minion **`id`** is safe to be used. Compromised minions cannot change **`id`** - Salt master would need to re-accept auth keys because key name changes together with minion **`id`** (they are co-named). Note that only minion **`id`** grain is used above in both cases. – uvsmtid Jul 25 '16 at 17:23
  • This is correct. Given, however, that there's no security model around "secure" and "insecure" grains, this is more of a side-effect than an intentional design decision. Therefore, I'd continue to recommend the first approach. – Michael Place Jul 26 '16 at 15:00
  • I think there should explicit distinction for `id` grain because _even the **1st** approach relies on it_. I like you called it "side-effect" - it reveals the fact that nobody planned for it. However, based on the comments I see, I would still allow both as perfectly valid. When `id` grain represents fundamental property of identity (which it is guaranteed to be correct as far as Salt's security can provide), the cases where we cannot rely on this grain should basically be treated as a bug. This "side-effect" becomes rather mandatory (the law) based on the choice of what `id` grain represents. – uvsmtid Jul 31 '16 at 03:36