Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require aesfunc tokens #7356

Closed

Conversation

dlanderson
Copy link
Contributor

See also #7353

The master currently allows any minion with an accepted key to send commands to the master as any other minion. This pull request requires that commands sent from a minion to the master include a token encrypted with the minion's public key.

Unfortunately, requiring this token breaks backwards compatibility with all previous minion versions. I have added "require_aes_tokens: False" to the master config, and the master will allow old minions to send commands without a token unless require_aes_tokens is set to True. I gave it a warn_until version 0.20 to allow for salt admins to upgrade their minions to at least 0.17 (assuming this pull request gets included in 0.17)

I think salt should, by default, not trust the minions as much as possible. This greatly reduces the ability of evil minions to do nasty things.

@thatch45
Copy link
Member

We should not refer to the token as aes and the verify as rsa, since these are routines that can be updated in the future and they are not cryptographic per-say. This is just a simple id challenge.
Also, this warning will FLOOD the logs and be a very bad thing. This warning should just be posted once when the master starts up

@dlanderson
Copy link
Contributor Author

@thatch45 you're right. I renamed them to be properly descriptive and moved the log deprecation so it only logs once, but I think I'm going to close this and refactor some things on a new branch.

@dlanderson dlanderson closed this Sep 19, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants