On Tue, Mar 14, 2017 at 11:14 AM, Lance Richardson <[email protected]> wrote:
> > 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 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 > > > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
