highstate.cache contains secrets

[darkpixel]

Description of Issue/Question

The highstate.cache.p file contains secret data.

Related to #28455

After reading through the documentation, I don't see a clear way to prevent strings in states or pillar data from being cached.

I played around with SDB using Hashicorp Vault as one suggested work-around. The secret data still ends up in the highstate.cache.p file.

Setup

Create a very simple luks.sls state like while changing 'xyz' to the ID of a drive you don't mind being destroyed:

init_drive:
  cmd.run:
   - name: echo -n secret-password-123 | /sbin/cryptsetup luksFormat /dev/disk/by-id/xyz -
   - unless: /sbin/cryptsetup isLuks /dev/disk/by-id/xyz
   - require_in:
     - unlock_drive

unlock_drive:
  cmd.run:
    - name: echo -n secret-password-123 | cryptsetup --key-file - luksOpen /dev/disk/by-id/xyz dm-crypt-xyz

will cause 'secret-password-123' to be cached.

Same with using Hashicorp Vault: echo -n {{ salt['vault'].read_secret('secret/luks', 'passphrase') }}

...or in the pillar data.

Am I missing something? Is there a way to keep secret data from remaining on the minion?

I would like to use salt to automate unlocking a bunch of encrypted drives, but I don't want a passphrase hanging around on the boot drive in case someone breaks in and steals the machine.

As a side note, salt-ssh doesn't appear to leave behind a cache, although I'm guessing it probably writes the secrets to the drive at some point.

Versions Report

Salt Version:
           Salt: 2017.7.4
 
Dependency Versions:
           cffi: 1.11.2
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.10
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.4.7
   mysql-python: Not Installed
      pycparser: 2.18
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 3.6.4 (default, Apr  5 2018, 01:17:42)
   python-gnupg: Not Installed
         PyYAML: 3.12
          PyZMQ: 17.0.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.3
 
System Versions:
           dist:   
         locale: UTF-8
        machine: amd64
        release: 11.1-RELEASE
         system: FreeBSD(Provided by running `salt --versions-report`. Please also mention any differences in master/minion versions.)
        version: Not Installed

[Ch3LL]

There is not a way to do this. as you can see from the docs here: https://docs.saltstack.com/en/latest/ref/modules/all/salt.modules.state.html#state-caching

note:

When a highstate is called, the minion automatically caches a copy of the last high data. If you then run a highstate with cache=True it will use that cached highdata and won't hit the fileserver except for salt:// links in the states themselves.

so its expected behavior to write to this highstate cache file each time.

[darkpixel]

I get that it's expected behavior, but I think that should be revisited. There are cases where you might want salt to do something on a minion (like unlock drives) and NOT leave that data lying around on a boot drive in case someone physically stole the minion box.

[Ch3LL]

We could possibly gate it around a config option. Ill approve as a feature.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[darkpixel]

I think this is still relevant.

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

[darkpixel]

Is there a way to turn off stalebot for feature requests? I've had to open ~8 tickets over the past 24 hours to tell stalebot to go to hell... Obviously the developers are unpaid volunteers who are busy...but bugging users to see if the feature they requested is still a feature they requested is a bit annoying. If anything stalebot should say "hey devs, have you implemented this yet?" ;)

[stale[bot]]

Thank you for updating this issue. It is no longer marked as stale.

[iMikeG6]

Hi,

I totally agree with @darkpixel

We are considering using salt for our managed servers, but the fact that the secrets could be visible by anyone who has sudo right is a big no no for us.

For now, as a workaround, I created a state file that remove the file on the minions:

clear_highstate_cache:
  file.absent:
    - name: "/var/cache/salt/minion/highstate.cache.p"

Not ideal, but it seems like it does the job. However, i'm wondering about the load of the salt master, as there's no cache on the minions anymore. I tested this solution with 3-4 minions and haven't noticed big load on the master, at least, not yet.

Another way is to clear the cache using this formula:

clear_highstate_cache:
  cmd.run:
    - name: "salt-call --local saltutil.clear_cache"

It works as well, but not sure which one is the best between the two.

Though, if we can have a better and cleaner solution from the devs, that be great.

I'm really surprise that after 5 years, there's still no option to either disable the cache or encrypting the file /var/cache/salt/minion/highstate.cache.p on the minion