Open mrueg opened 8 years ago
@mrueg, thanks for reporting. This seems like a great idea.
Register an OID for an SSL Cert with isot @ ansi.org Add values to the SSL certificate. i.e. if you sign it your accept the values as well.
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.
Should be kept open IMHO
Thank you for updating this issue. It is no longer marked as stale.
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.
Still needed
Thank you for updating this issue. It is no longer marked as stale.
If I look past the implementation specifics of this request, the issue is that we can't trust grains to not be compromised (because they are stored on the endpoint and any salt command can run grains.set()), and so we must assume that either a brute force or inside attack can compromise the pillar data.
I see three possible responses to this:
Don't associate pillar data with minions based on grain-based targets (thereby requiring either glob or list-based target for pillar files); this carries considerable management overhead (really big top or pillar files that can no longer be dynamic).
Prevent tampering with the grain data (what this method is proposing), which comes with its own set of issues:
Externalize the role data (don't store it on the minion) in a database or cmdb, which cannot be modified as part of a state run and that wraps an RBAC model around it such that some privileged users can change the values of these role "grains".
(okay, I lied, I can imagine four possibilities) Separate the environment using masters where "dev" masters only have "Dev" pillar data attached and "Prod" masters only have "prod" pillar data attached. This only solves the OPs supposition that a "developer could add production grains to a test server to steal production secrets". By separating the pillar data by master, this becomes impossible... but it doesn't prevent a similar attack such that a "production user" could create grains for other roles to siphon off the secrets from those other roles (but, again, this requires a-priori knowledge of what those roles would be - which could be done with a simple brute-force attack).
So I guess the question is, what is the OP trying to achieve? Protection from tampering of /etc/salt/grains using an editor, protecting production secrets from developers or enforcing "separation of duty"?
I really have no idea how this is supposed to work. The OP calls for 'master-issued grains' which IMHO is exactly what Pillar does.
But not before he laments that the (his?) Pillars' top.sls is using grains to determine which secrets get sent out where, together with an article pointing out exactly why this is such a bad idea by design.
As grains are by definition locally administered and configured, nothing will ever solve that. Want a salt-master to sign a received grain? All it can vouch for is what it received the first time, establishing 'trust' based on an insecure, locally administered config, rendering it total snake-oil IMHO. You want the salt master to provide grains? That's exactly what Pillar data already does. You want the CMDB to feed trustworthy info? As @dkfsalt notes, again, that's exactly what you can and should be doing with Pillar.
So I'm convinced that the current implementation is actually clean & clear-cut:
All that's apparently missing is documentation making that point way more clear.
Thanks for providing feedback, unfortunately this issue has seen its third birthday and I don't remember exactly what my original issue was. I don't use saltstack at the moment for state enforcement, so I would leave re-defining this issue to other interested users (as a few kept this issue open for quite a while).
My opinion is that if you want secure data use pillar or sdb or some external secret store (with a pillar driver). Grains were never designed to be secure in this manner. If you can't trust your minions to be honest or benign with their grains, you should just not trust them and instead use something that you can trust.
My perspective is that it would be better for salt core features to have more concrete roles so that, much like the zen of python there is more common guidance on how to apply salty principles to a given use case. If your goal is secure targeting and using pillar/sdb is not immediately obvious as the solution, then pillar/sdb (documentation) needs to be updated to work in (explain) more cases.
The idea is the minion certificate contains the roles/facts. As minion certificate is signed and therefore has integrity the roles can be trusted information within the certificate. Its part of an auto sign solution. You kick off a build of a server and provide it with a minion certificate already signed with the embedded role. Because you can trust this information from the minion, you can use it for targeting. Salt Master does not have to be the server signing the certificates.
The aim is not having to update to top file every time you build a new server, or having to add or maintain entries in pillar.
Register an OID for an SSL Cert with isot @ ansi.org Add values to the SSL certificate. i.e. if you sign it your accept the values as well.
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.
Not stale
Thank you for updating this issue. It is no longer marked as stale.
Would be very helpful to have
This is a feature request to improve the security on (e.g., role-based) grains. A possible scenario could have a production and development environment. The pillar's top.sls is using grains to decide which secrets (e.g. a tls priv key) are provided to each environment. As described in [1], a developer who has access to the development environment could add the production grains and get full access to the production secrets stored in the pillar.
Trusted grains could solve this issue by having the master issuing a signature on that grain, that is attached to the grain in some way and evaluated when hitting a grain during execution.
A possible signature for a single master setup (or multimaster sharing the same keys) could be a HMAC like HMAC(K,m) with m being a concatenation of the trusted grain variable name and the minion id, that is attached to the grain. A trusted grain renderer could then validate that the salt-master has issued that grain.
[1] https://docs.saltstack.com/en/latest/faq.html#is-targeting-using-grain-data-secure