Re: Access control [was: action RPC I-D]

[Andy Bierman <ietf@andybierman.com>]

Vincent Cridlig wrote:
> Andy Bierman a écrit :
> > Balazs Lengyel wrote:
> > > Hello,
> > > I feel that we should be careful not to make access control to 
> > > complicated. While technically it is possible to design a good, fine 
> > > grained access control model, I fear the user (operator) will have 
> > > difficulties understanding it.
> > >
> > > I see that read/write (and possibly disturb traffic) are three easy 
> > > to understand concepts that might be executed by different people in 
> > > the network operator's organization. On the other hand I don't see 
> > > who would be the operator who is allowed to modify a route(or a 
> > > customer), but not to create a new one.
> > >
> > > I agree that operationally separating delete, replace, etc. is a 
> > > useful notion, but I don't see the need for the same with access 
> > > control.
> >
> > I suggest that people implement NETCONF, and also implement
> > some kind of ACM, and prove to operators and the WG that the
> > design and feature set is necessary and sufficient.
>
>
> We have some kind of implemented ACM which assumes an XML data model.
> I don't know if it is necessary and sufficient ! Here is a quick overview:

Sounds very good to me.
I bet it could be easily extended to configure the RPC method
access control as a list of Xpath expressions.

There seems to be WG consensus that actions should not
be modeled as data, but rather as RPC methods.  Therefore,
restricting access to certain RPC methods (<delete-config>,
<reset-device>, etc.) is going to be important.

> Each permission is expressed with two things:
> - an XPath expression, saying which nodes are concerned,
> - an attribute which can be "r", "w", or "rw".

What happens if Xpath expressions overlap (i.e. 1 or more nodes
are selected by more than 1 Xpath expression)?  Do you just
execute the list in order, like an ACL on a router?

I am giving in on the "create/delete" feature in the ACM.
The fact is that this is more effort to implement and
takes more runtime cycles, because you have to check the
actual configuration database to know if a merge or replace
is really a create or delete.

If the ACM allows for read/write, then you only have to check
the PDU, not the configuration target as well.

BTW, I like the enum "w" -- it is useful for storing keys and
passwords in configuration databases.


> In our implementation, having access to one node grants the privilege to 
> the whole subtree of this node. Only positive privileges can be 
> specified to avoid conflicts.
>
> Also, since we implemented an RBAC model, we define roles like 
> SuperManager, RoutingManager, ExteriorRoutingManager, SecurityManager 
> and so on... These roles have some permissions, and each manager may 
> have some roles. (Roles can be hierarchical if you need.)
>
> For people who think it is not necessary to have such fine-grained ACM, 
> they can use the SuperManagerRole and give access to everything. For the 
> others, they can specify privileges more carefully.
>
> One of the cool thing is that the scope of operations is limited when 
> you have one role active. This decreases misconfigurations risks. There 
> are other advantages.

Sounds interesting.
You should write a draft about it.

> Regards,
> Vincent
>
>
> > > Balazs
> >
> > Andy


Andy

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>