On Wed, Apr 12, 2017 at 09:30:42AM -0400, Lance Richardson wrote: > > From: "Lance Richardson" <lrich...@redhat.com> > > To: "Ben Pfaff" <b...@ovn.org> > > Cc: d...@openvswitch.org, "mickeys dev" <mickeys....@gmail.com>, "Russell > > Bryant" <russ...@ovn.org> > > Sent: Thursday, 6 April, 2017 12:19:46 PM > > Subject: Re: [RFC 0/5] role-based access controls for ovsdb-server, ovn-sb > > > > > From: "Ben Pfaff" <b...@ovn.org> > > > To: "Lance Richardson" <lrich...@redhat.com> > > > Cc: d...@openvswitch.org, russe...@ovn.org, "mickeys dev" > > > <mickeys....@gmail.com> > > > Sent: Thursday, 6 April, 2017 12:03:44 PM > > > Subject: Re: [RFC 0/5] role-based access controls for ovsdb-server, ovn-sb > > > > > > On Mon, Mar 27, 2017 at 02:56:08PM -0400, Lance Richardson wrote: > > > > This series implements role-based access control infrastructure for > > > > ovsdb-server, and uses that infrastructure to apply role-based access > > > > controls to the OVN_Southbound database. This implementation follows > > > > the outline discussed at: > > > > > > > > > > > > https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329801.html > > > > > > > > With this series applied, enabling role-based ACLs is a matter of: > > > > > > > > - Configuring southbound ovsdb-server and ovn-controller to use SSL, > > > > configuring an ovn-controller "role" for SSL connections via e.g.: > > > > ovn-sbctl set-connection role=ovn-controller pssl:6642 > > > > - Using unique certificates for each ovn-controller with a unique > > > > CN for each chassis, generated e.g. via: > > > > ovs-pki -B 1024 req+sign chassis1 switch > > > > ovs-pki -B 1024 req+sign chassis2 switch > > > > ovs-pki -B 1024 req+sign chassis3 switch > > > > - Starting the southbound ovsdb-server with the "--rbac" > > > > command-line > > > > option: > > > > --rbac=db:OVN_Southbound,RBAC_Role > > > > > > This series is promising. > > > > > > I'm a little concerned about additional per-DB command-line options > > > because it makes it hard to add and remove databases at runtime. > > > > > Hi Ben, > > Could we extend the database schema format to add something like: > > "_rbac_role": <rbac-role-table-id> > > If so, I think we could eliminate the need to do anything extra for RBAC > support as databases are added/removed at runtime, and the --rbac= command- > line option would no longer be necessary.
It's difficult to gracefully extend the database schema format because of downgrades: if you start from an upgraded schema and then want to downgrade to an older version of the schema, you can only do it with a newer ovsdb-tool that understands the new feature, because the older version of ovsdb-tool will reject it. (The schema language could have been designed better to avoid this problem in common cases, but I was not insightful enough at the time.) So, except for very important features, I prefer to avoid extending the schema format. In this case, I'm having trouble seeing the harm if ovsdb-server simply treats any table named "RBAC_Role" as the RBAC role table. I guess that there is a risk that someone could start an older ovsdb-server with such a schema, expecting that the RBACs are in effect, but actually leaving the server fully open to any client. I don't know whether that is something to worry about. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
