[ovs-dev] [RFC] ovn: minimize the impact of a compromised chassis

Russell Bryant russell at ovn.org
Mon Aug 22 17:14:03 UTC 2016


On Mon, Aug 22, 2016 at 12:30 PM, Ben Pfaff <blp at ovn.org> wrote:

> On Tue, Aug 16, 2016 at 09:30:21AM -0400, Lance Richardson wrote:
> > As described in ovn/TODO, these are the two main approaches that could be
> > used to minimize the impact of a compromised chassis on the rest of an
> > OVN OVN network:
> >
> >   1) Implement a role- or identity-based access control mechanism for
> >      ovsdb-server and use it to limit ovn-controller write access to
> >      tables in the southbound database.
> >
> > or
> >
> >   2) Disallow all write access to the southbound database by
> ovn-controller
> >      (as an optional mode or unconditionally) and provide alternative
> >      mechanisms for updating the southbound database for entries that are
> >      currently updated by ovn-controller.
> >
> > It is believed that option (1) would require somewhat more effort than
> (2),
> > and, because it would involve significant modifications to ovsdb-server,
> > would also be more likely to add risk and burden to non-OVN users.
> > Additionally, option (2) will likely place fewer requirements on
> alternative
> > databases (such as etcd), so the following implementation discussion only
> > considers option (2).
>
> I've always pushed back against adding granular access control
> mechanisms to OVSDB because I didn't believe it was likely that anything
> that was simple enough to be in the "spirit of OVSDB" (heh) was also
> going to be sufficient to fit a real use case.  However, if we do now
> have specific requirements for OVN, then I'd invite descriptions of what
> access control mechanism would be sufficient.  If it's simple and
> general enough, then implementing it in OVSDB might totally make sense.
>
> I don't think that the "risk and burden" of a simple and general
> mechanism is a real issue.


I think that push back makes sense.

The proposal here was to take route #2.  The only OVSDB feature required in
that case is to accept read-only connections, which could be on a
per-socket basis.  This seems much simpler all around, as long as we can
all get on board with ovn-controller as a read-only client.

Are you interested in looking closer at what #1 would look like, with
details of what the access control policy would look like?

-- 
Russell Bryant



More information about the dev mailing list