On Fri, 2007-10-12 at 11:05 -0400, Karl MacMillan wrote: > > kerberos is pain and death to every project I've ever worked on. The > > moment it is added the requirements explode and the application becomes > > a 'special case'. > > > > Why? I'd be interested in some more detail. the maintenance and care of kerberos servers makes everything a mess, not to mention integrating these with most common applications. The ticket expirations, the mucking about with 3rd party apps to make them work. It's just a world of fun. We went down this path with urlgrabber a while back and the answer was 'ugh, no, stop, run away'. > But why prevent it working if you have that infrastructure? Many shops > want to centralize their identity - both machine and user - so working > with central identity seems like a huge win. actually, that's not true. Many MANAGERS want to centralize their identity. Most admins want to keep hosts and users as VERY different concepts. Managers want it b/c they think it means they can cut down head count b/c they'll have fewer pieces to manage. > > If a rogue master can spoof the master on the network then your network > > has very much other problems. > Not particularly - it is very easy to do this type of spoofing and > preventing it is just good protocol design. And in the whole scenario you have to get bits onto the minion that you trust somehow. Your options are: put them in a pkg and trust that the deployment server is not compromised or spoofed. Which is the same as the what you're describing above. so we've not won anything. We have to have an entry point of trust. We've chosen ours at the same place puppet chose theirs. > That does not agree at all with my experience (and I have worked as a > sysadmin). For how long did you work as a sysadmin and for what kind of systems? I was an admin for both small, medium and large scale infrastructure. In all cases if setting up the infrastructure meant bringing up anything larger than a single process then you had to go into a meeting to determine if you could do it. meetings are death. So in most cases you just avoided anything that required infrastructure. You'll notice that people love setting up yum repos on an already existing http server b/c they're no-infrastructure required. But setting up RHN requires an act of congress and makes most people want to shoot themselves. There's a reason for that. > More importantly, however, is the ability to control malicious software. > Even if the total authority granted to the admin is equivalent to root, > running each component with less privilege will prevent a small error / > exploit from becoming a complete compromise of every system controlled > by func. Do you really not see the danger you are creating here? no more than the danger present by ssh and ssh keys. Again, we've just taken on 'the danger' that another tool has - we've just made it more realistic for sysadmins to use. > I understand the convenience and usability goals, but no one will thank > you for creating the perfect platform for the total compromise of their > entire network. We're not making the network any more vulnerable than ssh, puppet, rhn or cfengine make it. And those are all recommended solutions. -sv
