Answers: <p>There is currently one safe way to do this.</p>
  
  <p>You can use <code>{{opts.id}}</code> as an explicit way to grab the minion ID. <code>opts</code> is technically an implementation detail; the <code>opts</code> dictionary is a Salt <a href="https://docs.saltstack.com/en/latest/ref/internals/opts.html" rel="nofollow noreferrer">internal structure</a> that doesn't appear to be formally specified. Its candidacy for the purpose was pointed out to me in a <a href="https://github.com/saltstack/salt/issues/41568#issuecomment-306968291" rel="nofollow noreferrer">bug comment</a>.</p>
  
  <p>In the next version of Salt (so, later than 2016.11.5) the <code>id</code> grain, will have been <a href="https://github.com/saltstack/salt/issues/10212" rel="nofollow noreferrer">special-cased</a>, making it possible to use <code>{{grains.id}}</code> safely.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-05T15:57:22.003Z
Answers: 2017-06-08T12:24:15.630Z
Answers: 2017-06-08T12:24:15.630Z
Answers: Michael Mol
Body: <p>I found this SLS file in a pillar top.sls targeting example:</p>
  
  <p><code>top.sls</code>:</p>
  
  <pre><code>base:
    '*':
      - hostspecificsls
  </code></pre>
  
  <p><code>hostspecificsls</code>:</p>
  
  <pre><code># See https://groups.google.com/forum/#!topic/salt-users/UWfP6bMe6F8
  {% include 'hosts/' + salt['grains.get']('fqdn') + '.sls' ignore missing %}
  </code></pre>
  
  <p>This strikes me as distinctly insecure, as it runs counter to one of the <a href="https://docs.saltstack.com/en/latest/topics/best_practices.html#general-rules" rel="noreferrer">Salt Best Practices</a>:</p>
  
  <blockquote>
    <p>Don't use grains for matching in your pillar top file for any sensitive pillars.</p>
  </blockquote>
  
  <p>Why is this insecure? Well, grains are evaluated <em>on the minion</em>, 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. </p>
  
  <p>Fortunately, there's a (theoretical) solution; use the minion ID. Minion IDs are unique, and they're verified on the master cryptographically.</p>
  
  <p>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.</p>
  
  <p>So how can I get at the master's concept of the minion ID from Jinja on the master?</p>
  
Tags: <salt><jinja><pillar>
Title: Securely grab minion ID in pillar top file template?
UserDisplayName: Michael Mol
ThreadText: # Securely grab minion ID in pillar top file template?
  
  (Asked by: username_0 on 2017-06-02)
  
  I found this SLS file in a pillar top.sls targeting example:
  
  `top.sls`:
  
  ```
  base:
    '*':
      - hostspecificsls
  
  ```
  
  `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](https://docs.saltstack.com/en/latest/topics/best_practices.html#general-rules):
  
  > 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?
  
  **Tags:** salt, jinja, pillar
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-06-05. Score: 3 | Accepted answer
  
  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](https://docs.saltstack.com/en/latest/ref/internals/opts.html) that doesn't appear to be formally specified. Its candidacy for the purpose was pointed out to me in a [bug comment](https://github.com/saltstack/salt/issues/41568#issuecomment-306968291).
  
  In the next version of Salt (so, later than 2016.11.5) the `id` grain, will have been [special-cased](https://github.com/saltstack/salt/issues/10212), making it possible to use `{{grains.id}}` safely.
  
  
  ---
  
  