[DOCS] Conflicting information on grains and storing passwords: Deprecate salt.modules.grains.get_or_set_hash

[ScriptAutomate]

Description

Salt best practices direct users to use the pillar or SDB for storing sensitive data, such as passwords. Outside of documentation, we explicitly advise users not to store passwords in grains on minions, but this is only implied by the documentation.

This gets more complicated with the existence of this execution module function:

• grains.get_or_set_hash
  • Initial commit

Suggested Fix

• Deprecate grains.get_or_set_hash
• Create a .. warning:: admonition rst file that should be included with .. include:: in a variety of documentation endpoints:
  • Hardening Guide
  • Salt Best Practices
  • Grains
    • Likely somewhere in Grains: Writing Grains
  • Section of FAQ: Is targeting using grain data secure?
    • Maybe this answer should be modified?

The warning admonition could be along the lines of:

.. warning::

   Grains can be set by users that have access to the minion configuration files on
   the local system, making them less secure than other identifiers in Salt. Avoid
   storing sensitive data, such as passwords or keys, on minions. Instead, make
   use of :ref:`pillar` and/or :ref:`sdb`.

Type of documentation

• Salt documentation
• Salt modules

Additional context

Related issues:

• Grains insecure for targeting sensitive data #43287

[OrangeDog]

Just seen this in the release notes. What's the alternative when you want every minion to have a random unique value, and someone with root access to the minion changing it is not an issue?

get_or_set_hash is the only way I can see to do it automatically at scale.

[OrangeDog]

Never got any answer for this, and it's a bit late now.

You now have to replace a very simple system that was perfectly secure in many models with an entirely separate external database.

I'm just going to re-add get_or_set_hash as a custom module.