[Bind10-uides] results of a kibitz with Ben

[Jerry Scharf]

Hi,

Ben and I talked for a while last night. We did a little work as well. 
We kind of concentrated on the types of operational issues that might be 
encountered and how this would shape the tool requirements. This is no 
particular order.

If we had an RBAC system, how would one specify a rule based version of 
the two person signoff rule?

How do we put locks on upper level objects. We talked about a bunch of 
ideas, but found one that best identified the need. Say part of the 
management datastore was actually imported from another system. For 
reasons beyond our control, there will be a window where the other 
systems data will be inconsistent. We will need to prevent any of the 
objects related to that store from changing, lest things start 
disappearing and appearing with bad results.

Has anyone even seen positive and negative role matching for rbac? Could 
you turn off all access to a node by having a hierarchical role 
structure and then putting in !someone at the head of the access list? 
We also had a great laugh that we wanted to have a role called nobody. 
That way when someone says nobody can touch it, I know they are talking 
about me. :)

We talked a bit about comments and tickets. We decided that we should 
have a opaque blob (maybe a uint64) down in the resource records and 
then have the management side take the rr info and the blob and figure 
out all the pieces that are available from there. I think there needs to 
be some more thought on how this backtracking works in an expandable way.

We came up with at least a partial list of things that ops people would 
really like to havebeyond being able to create, update and delete rrs 
and controls:
comment and ticket stored (i know you can stick the ticket in the 
comment, but I hate that)
audit trails
users, rbac and acls (possibly crud, possibly more) it's really hard to 
separate these
transaction logic (begin, commit, rollback)
being able to do expanded queries down the management path and get extra 
data
being able to do DNS queries from the tool
being able to examine the logs and stats from the tool

We thought that comments, tickets and audits without users would be a 
doable and interesting first set of added functions. Or maybe we even 
punt audits till the second round.

Things that are in the core of the tools would be

data model and store
related action functions, most importantly translate to RFC and bind10 
objects
display functions
templates
one validation script

We started talking a bit about the objects in the data abstraction, but 
that isn't near far enough along to put anything down. We were thinking 
fairly hierarchically about objects, servers were a type of host and 
namesever was a type of server...

Ben one thing we missed was the concept of a cluster. So this set of 
hosts are treated as a group when attached somewhere instead of a single 
entity. An example would be "these are the set of mail servers for the 
americas" and could be used anywhere a single mail server is allowed.

extracting zone cuts as a top level entity has some pretty cool effects. 
Things like "insert zone cut" become a relatively simple operation. 
"remove a zone cut" takes a bit more care (what if the parent and child 
zones have a different MX set for *.)