[ovs-dev] OVN: Compromised Chassis Mitigation

Lance Richardson lrichard at redhat.com
Tue Mar 14 20:11:44 UTC 2017 


----- Original Message -----
> From: "Mickey Spiegel" <mickeys.dev at gmail.com>
> To: "Lance Richardson" <lrichard at redhat.com>
> Cc: "Russell Bryant" <russell at ovn.org>, "devovs" <dev at openvswitch.org>
> 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 <lrichard at redhat.com>
> wrote:
> 
> >
> >
> > ----- Original Message -----
> > > From: "Mickey Spiegel" <mickeys.dev at gmail.com>
> > > To: "Lance Richardson" <lrichard at redhat.com>
> > > Cc: "Russell Bryant" <russell at ovn.org>, "devovs" <dev at openvswitch.org>
> > > 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 <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 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
> > > > >
> > > >
> > > >
> > >
> >
>

More information about the dev mailing list