Password leakage risk #13

New issue

Closed

opened 2022-09-08 15:38:41 -05:00 by ejparker · 2 comments

ejparker commented

2022-09-08 15:38:41 -05:00

Owner

The fix is to directly rely on pillar data instead of using pillar data to fill grain data and basing roles off the resulting grain data. This could cause complications with some of the build states since they should ideally be run prior to the relevant maintain states, though there are only a few servers that have build states.

Relying on grains to determine server roles could risk leaking passwords if a minion is compromised - an attacker could alter the grains file on the minion, run highstate and the roles would be applied before the grains file is properly updated. The fix is to directly rely on pillar data instead of using pillar data to fill grain data and basing roles off the resulting grain data. This could cause complications with some of the build states since they should ideally be run prior to the relevant maintain states, though there are only a few servers that have build states.

ejparker commented

2022-09-08 15:39:51 -05:00

Author

Owner

fixed with 57f6066c45

fixed with 57f6066c45

ejparker closed this issue

2022-09-08 15:39:58 -05:00

ejparker commented

2022-09-08 15:43:20 -05:00

Author

Owner

This also creates an issue with role desync between pillars and states - since pillars are currently still relying on grain data to determine roles.

Unfortuantely pillar files can't use pillar data to determine roles (for obvious reasons), so an alternative solution needs to be implemented - see #14

This also creates an issue with role desync between pillars and states - since pillars are currently still relying on grain data to determine roles. Unfortuantely pillar files can't use pillar data to determine roles (for obvious reasons), so an alternative solution needs to be implemented - see #14

ejparker referenced this issue

2022-09-08 16:32:01 -05:00

Pillar leakage risk and desync issue #14