> From: "Russell Bryant" <[email protected]> > To: "Mickey Spiegel" <[email protected]> > Cc: "Lance Richardson" <[email protected]>, "devovs" <[email protected]> > 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 <[email protected]> > 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 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 > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
