I found this SLS file in a pillar top.sls targeting example:


    - hostspecificsls


# See https://groups.google.com/forum/#!topic/salt-users/UWfP6bMe6F8
{% include 'hosts/' + salt['grains.get']('fqdn') + '.sls' ignore missing %}

This strikes me as distinctly insecure, as it runs counter to one of the Salt Best Practices:

Don't use grains for matching in your pillar top file for any sensitive pillars.

Why is this insecure? Well, grains are evaluated on the minion, so if a minion is sufficiently compromised, it can return whatever an attacker wishes for an arbitrary grain call. A compromised minion might claim to be an SSL (or VPN!) terminator to get at private key material, for example.

Fortunately, there's a (theoretical) solution; use the minion ID. Minion IDs are unique, and they're verified on the master cryptographically.

Except I can't find how to get at the minion ID without depending on grains. Remember, the grains are executed on the minion, so even if the Salt master knows at the transport layer what the minion ID is, if you query for the minion ID via grains, you're asking the minion for the ID, not the master.

So how can I get at the master's concept of the minion ID from Jinja on the master?

1 Answer 1


There is currently one safe way to do this.

You can use {{opts.id}} as an explicit way to grab the minion ID. opts is technically an implementation detail; the opts dictionary is a Salt internal structure that doesn't appear to be formally specified. Its candidacy for the purpose was pointed out to me in a bug comment.

In the next version of Salt (so, later than 2016.11.5) the id grain, will have been special-cased, making it possible to use {{grains.id}} safely.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.