[PLUG] Negative namespace deltas

[Tim]

Hello Paul,

On Tue, Apr 15, 2008 at 09:18:54AM -0700, Paul Heinlein wrote:
> This is an "Ask Slashdot" sort of question:
> 
>    What are your best practices for maintaining negative
>    namespace deltas?
> 
> I maintain the typical sort of system namespaces -- DNS hostnames and 
> cnames, DHCP MAC tables, e-mail aliases -- along with what I imagine 
> are more atypical ones like Xen virtual hosts and Trac (wiki) 
> instances.
> 
> Adding to those namespaces is a clear process: someone submits a 
> ticket and I push the relevant bits into production.
> 
> Subtracting from those namespaces is murkier. People don't always tell 
> me when a system has retired or an e-mail alias is obsolete. Those 
> namespace entries lurk like so much kruft in my config files.
> 
> What are the best methods you've developed for identifying negative 
> deltas and getting the appropriate customer to approve the change?


This is a good question.  While I haven't had to deal with this issue
specifically related to the configuration elements you listed, I have
worked in security departments where the issue was about user accounts.
The same problem comes up with contractors and "process" accounts
(network accounts assigned for daemons and other automated processes).

Managers are all too eager to get an account set up for what ever their
project is, but they are very bad at asking those accounts to be
disabled when they are done.  Since this does have a significant
security impact over time, the approach to deal with it was somewhat
heavy handed (which may not be possible in your case).  Any account
granted in certain classes (essentially for non-employees) must have an
expiration date.  Managers are notified shortly before that date to
ensure they don't need the account any more.  If not, or if there is no
response, the account is disabled.

Of course this tends to anger lots of managers, but the trade off is
reasonable.  In your situation, it may not be as reasonable for most of
the configurations you listed.  However, for others, such as firewall
rule changes and external DNS configurations, it might be reasonable to
have expiration dates.  Perhaps if someone needs a permanent change with
no expiration, a management person higher up in the food chain should be
required to authorize it. 

Not a great answer, but hope that gives you some ideas.
tim