----- Original Message ----- > From: "Mickey Spiegel" <[email protected]> > To: "Lance Richardson" <[email protected]> > Cc: "Russell Bryant" <[email protected]>, "devovs" <[email protected]> > Sent: Tuesday, March 14, 2017 3:06:53 PM > Subject: Re: [ovs-dev] OVN: Compromised Chassis Mitigation > > On Tue, Mar 14, 2017 at 12:01 PM, Lance Richardson <[email protected]> > wrote: > > > > > > > ----- Original Message ----- > > > From: "Mickey Spiegel" <[email protected]> > > > To: "Lance Richardson" <[email protected]> > > > Cc: "Russell Bryant" <[email protected]>, "devovs" <[email protected]> > > > Sent: Tuesday, March 14, 2017 2:27:30 PM > > > Subject: Re: [ovs-dev] OVN: Compromised Chassis Mitigation > > > > > > 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 was suggesting a simplification that would eliminate the need for that > > indirection by having the remote refer directly to an ACL/Permissions > > table. The drawback to this simplification would be having to modify > > the db schema in order to add a new role (a new ACL/Permissions table > > would be needed for each added role), versus being able to define > > new roles and rule sets dynamically. For OVN_Southbound, this doesn't > > seem to be much of a drawback since we're currently only envisioning > > one role needing ACLs (ovn-sbctl, ovn-northd, etc. would continue to > > use read-write sessions without ACLs. > > > > lance > > > > > I guess another alternative is to have row just be a column in the > > > ACL / Permissions table. > > > > s/row/role > > This would be almost the same as what you have suggested, > except no need to change the schema when a new role is > added. > > The difference between this and the indirection that I suggested > earlier is that ACL/Permission rows could not be shared between > roles. >
Right, the indirection table does seem to add value. So, we would stick with adding a new "role" column to the Connection table, the value of this column is used to index the appropriate row in the "Roles" table, and the "Roles" table has a column containing a map of string:UUID (table name to RBAC_Permissions row). RBAC_Permissions for the OVN_Southbound case would contain: "Chassis": authorization: "chassis" insert_delete: "true" update: "nb_cfg", "external_ids", "encaps", "vtep_logical_switches" Modification of these columns is allowed for rows for which the authorization check passes. "Encap": authorization: "chassis" New column containing CN ID of row creator. insert_delete: "true" update: "type", "options", "ip" "Port_Binding": authorization: "" All chassis are considered to be authorized. In a recent live migration proposal by Russell Bryant, this column would contain "options:chassis" and "options:migration-destination". insert_delete: "false" update: "chassis" "MAC_Binding": authorization: "" All chassis are allowed to update/delete any row. The long- term plan would be to eliminate this table. insert_delete: "true" update: "logical_port", "ip", "mac", "datapath" Regards, Lance > Mickey > > > > > > > > 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
