[ovs-dev] OVN: Compromised Chassis Mitigation

Mickey Spiegel mickeys.dev at gmail.com
Tue Mar 14 18:27:30 UTC 2017


On Tue, Mar 14, 2017 at 11:14 AM, Lance Richardson <lrichard at redhat.com>
wrote:

> > From: "Russell Bryant" <russell at ovn.org>
> > To: "Mickey Spiegel" <mickeys.dev at gmail.com>
> > Cc: "Lance Richardson" <lrichard at redhat.com>, "devovs" <
> dev at openvswitch.org>
> > Sent: Tuesday, March 14, 2017 1:48:55 PM
> > Subject: Re: [ovs-dev] OVN: Compromised Chassis Mitigation
> >
> > On Tue, Mar 14, 2017 at 5:08 AM, Mickey Spiegel <mickeys.dev at gmail.com>
> > wrote:
> > >>       - An "authorization" column containing a set of "string" type,
> where
> > >>         each string is the name of a column (or column:key) that must
> > >> contain
> > >>         the ID of client attempting the transaction (CN field from
> client
> > >>         certificate). If this set is empty, all IDs are considered to
> be
> > >>         authorized.  If this set contains more than one string, at
> least
> > >> one
> > >>         must contain the client ID in order to be considered
> authorized.
> > >
> > >
> > > This is the "where" column in the RBAC approach, where the "CN = "
> > > part of the logical expression is implied, and only the column part is
> > > specified.
> > >
> > > When access is attempted from an ovn-controller, then the
> > > authorization rule applies. However, there are other things
> > > accessing OVN SB DB that are allowed to change these things
> > > even though they do not have a CN, or at least not one that
> > > looks like a chassis name. For example, ovn-northd.
> > > How is this controlled?
> > > This is exactly why the indirection through role is suggested, to
> > > allow access to various things without hardcoding specific logic
> > > to determine what is subject to the rules.
> >
> >
> > I had imagined we'd deploy OVN such that ovn-northd would connect to a
> > different ovsdb remote that didn't have ACLs turned on.
> >
>
> I think we do need a way to specify whether ACLs should be applied to
> transactions on a given client connection.
>
> We could have ACLs implicitly apply only to read-only connections, but
> I think it would be better to make this an explicit configuration item.
>
> One way to do this would be to add a "role" attribute to each remote and
> have a table to map "role" to a specific ACL table.
>
> We could also consider adding an ACL table reference column to the
> OVN_Southbound "Connection" table and make ACLs part of remote
> configuration; if an ACL table is configured for a particular remote,
> ACLs from that table would be used for transactions on that remote.
>

I don't follow. What are the definitions of ACL table and the reference?

I thought there is only one ACL / Permissions table. The reason for
the indirection through "role" is to identify the rows in the table that
apply. There may be multiple rows that apply.

I guess another alternative is to have row just be a column in the
ACL / Permissions table.

Mickey


> I think either approach would provide similar flexibility, the
> second seems a little more straightforward.
>
> Thoughts?
>
> Thanks,
>
>    Lance
>
> > Currently, our OpenStack deployment always co-locates ovn-northd with
> > the OVN databases, so it just connects over a unix socket.
> >
> > --
> > Russell Bryant
> >
>
>


More information about the dev mailing list