help-cfengine
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Tiered admins with cfengine / dual control


From: Martin, Jason H
Subject: RE: Tiered admins with cfengine / dual control
Date: Thu, 13 Oct 2005 11:03:23 -0700

In your example of Opsware/Bladelogic, what keeps the person who
configures the roles from giving themselves full access and doing
something untoward?  Or, what keeps the DBA from manipulating the DB to
perform the same action?  I'm primarily concerned with mitigating the
ability of any one admin (of the tool, database, or machine containing
either) from bypassing whatever procedural controls that are in place
and doing damage without any oversight. 

-Jason Martin


> -----Original Message-----
> From: 
> help-cfengine-bounces+jason.h.martin=cingular.com@gnu.org 
> [mailto:help-cfengine-bounces+jason.h.martin=cingular.com@gnu.
> org] On Behalf Of Luke Kanies
> Sent: Thursday, October 13, 2005 10:47 AM
> To: help-cfengine@gnu.org
> Subject: RE: Tiered admins with cfengine / dual control
> 
> 
> On Thu, 13 Oct 2005, Martin, Jason H wrote:
> 
> > Along the same lines, has anyone implemented a system such 
> that there 
> > is no one person capable of pushing out changes?  I'm 
> talking about a 
> > system analogous to the nuclear missile keys that require 2 
> people to 
> > agree to launch.
> >
> > The scenario here is how would the college protect itself 
> from Jason 
> > Edgecombe, as a top-level SA, deciding to bring down the entire 
> > university infrastruture.
> >
> > CFE doesn't support this directly, but perhaps it could be 
> managed via 
> > a module. I'm thinking it'd have to be based on two 
> different master 
> > servers agreeing on a configuration, with discrepencies 
> causing CFE to 
> > fail into a internal-maintenance-only mode. Assuming that 
> each master 
> > server has a mutually exclusive set of root users, it'd have to be 
> > something that none of them could subvert on their own.
> 
> This is generally called 'change management' (as opposed to 
> normal usage of cfengine, which would qualify as 
> 'configuration management'), and is the next problem 
> typically encountered when config mgmt is brought under control.
> 
> There's a lot more to it than just who signs off, of course 
> -- things like migrating from one version of a configuration 
> to another, upgrading sets of applications (e.g., new 
> versions of a three tier web architecture), making changes 
> slowly, so that not all systems are upgraded at the same time 
> (thus potentially causing an outage when all of your web 
> servers reload their configs), and plenty else.
> 
> Some of the commercial tools (BladeLogic and OpsWare) make 
> some stabs at this, although I wouldn't say any of them have 
> solved it, but I haven't seen any of the OSS tools even try 
> for it yet.  That's one of the things I probably should have 
> mentioned about OpsWare vs. cfengine -- both OpsWare and 
> BladeLogic are backed by databases, not flat files, and 
> they've implemented role-based access control to the 
> databases (notably _not_ the systems, just the db that 
> controls the configs for the systems).  That can make a big 
> difference for some shops.
> 
> It's definitely not a simple problem, and it brings up the 
> whole 'roles' problem, which is somewhat unsolveable with 
> flat files like cfengine (and puppet) uses.
> 
> -- 
> True Terror is to wake up one morning and discover that your high
> school class is running the country.     -- Kurt Vonnegut
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | 
> http://config-mgmt.blogspot.com
> 
> 
> 
> 
> _______________________________________________
> Help-cfengine mailing list
> Help-cfengine@gnu.org 
> http://lists.gnu.org/mailman/listinfo/help-> cfengine
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]