3 ms·
> requiring a config push each node each time you hire, > fire, forget a passphrase, or rotate a key is just asking > for disaster. What's the reason for t
by falsedan 10y ago
> requiring a config push each node each time you hire,
> fire, forget a passphrase, or rotate a key is just asking
> for disaster.
What's the reason for this paranoia? You have plenty of lead time before a new employee joins, or a key needs to be rotated (and you want to have the keys be valid for an overlapping period anyway). Even forgotten/replacement keys can be pushed out quickly.
I guess it's the fear of a disgruntled ex-employee trashing the systems in the minutes before the config management system removed their key? They could still keep an authenticated session open, but I feel that civil/criminal charges for unauthorized access are more effective protection than technology enforcement.
- subway 10y agoIt's less about paranoia, and more about reducing change operations on hosts. Why should I constantly update each host with information about who can access what resource with which credentials, when I can configure them a single time to delegate access control to a directory service?
- sliken 10y agoDespite the best intentions I've seen quite a few organizations crippled by having a directory service die. I'd much rather have a push based service (like configuration management) where downtime means people can't change their passwords. Having every login fail because a directory service is down seems silly. Not like the mapping of users <-> systems is particularly large, even for the largest organizations.
- subway 10y agoDo you take the same approach with DNS?