On Fri, 2007-10-12 at 13:43 -0400, seth vidal wrote: > On Fri, 2007-10-12 at 12:58 -0400, Karl MacMillan wrote: > > On Fri, 2007-10-12 at 11:19 -0400, seth vidal wrote: > > > On Fri, 2007-10-12 at 11:05 -0400, Karl MacMillan wrote: > > [...] > > > > > > > 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. > > > > > > > Let me try to push the conversation in a more positive direction. I'm > > trying to say two things: > > > > 1) Your current security mechanisms and implementation present some > > security risk. You may ultimately decide that the risk is warranted > > given the benefits - a position I disagree with - but I at least think > > you should adequately understand and evaluate the risk. > > > > 2) I think that adding some access control would make your software > > _more_ useful not less. This is based on my own experience and users > > that I talk with. Again, you may determine that adding these features is > > not what you want to do. > > > > Have you looked at the ACLs that are in git now? > > cn+cert-hash: methods, allowed, to, execute > > so only certain keys are allowed to run certain things. > the default mode is to not be allowed to run anything. > > I checked it in last week - it's not in a released version, yet. > Haven't seen it, but something like that seems good. I also think that separating out actions into separate processes would really help. You guys will never be able to implement good access control in the face of very flexible modules (like an ssh equivalent), so using separate processes lets you punt to OS level access control. Speaking of that, I was wondering what you guys think is the most interesting thing about func. So far I've seen basically 3 interesting bits (there is likely more that I am missing): 1) Managing multiple systems at once w/ the possibility of globbing (and grouping later I guess). 2) Simplified scripting of commands for running on many systems. 3) An xml-rpc infrastructure with simplified auth to make it all work. To me, 1 and 2 are the most compelling aspects and 3 seems to overlap quite a bit with ssh. Which leads to my question - have you thought about just leveraging ssh? You could do auth with ssh keys (which could be just as convenient as you current scheme) and you get all of the security benefits of ssh (privilege sep / mapping of actions to users or privilege levels / separate processes for each invocation / mutual auth through key distribution). I know it also likely make some things harder. I believe this is the approach of capistrano. Just wondering. Karl
