On Wed, Mar 15, 2017 at 7:18 AM, Lance Richardson <[email protected]> wrote:
> > 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 > > > > Hi Mickey, > > Thanks for the excellent feedback. Here's the latest pass: > Thanks for driving this. All of this looks good to me :-) I hope others can provide some feedback on the question at the bottom. Mickey > 1) Add a new column, "role", of type "string" to the remote connection > table. If set, role-based access control is applied to transactions > on these connections using "role" as the index to the "RBAC_Roles" > table. If not set, role-based access control is not applied (e.g. > local unix: remotes between northd and ovsdb will not require RBAC > and will therefore not set the "role" column). > > For connections having role-based ACLs enabled, a reliable client ID > is required. This will require the use of SSL and client certificates > with CN field containing the client ID. > > 2) Add a new table, "RBAC_Roles", which is indexed by a role name > and contains two columns: > "name": Name of role, type string. Corresponds to "role" > column in remote connection table. > "permissions": A map of string (table name) to UUID (row in the > "RBAC_Permissions" table). > > The purpose of this table is to select a row in the RBAC_Permissions > table based on the transaction client's "role" and the name of a > table to be modified by an operation within a transaction. Having > this level of indirection allows new roles and access controls to > be created and managed dynamically, without having to update code > or schemas. > > 3) Add a new table, "RBAC_Permissions" which is initialized to contain one > row for each table in the schema that can be modified by ovn-controller. > Each row contains: > > - An "authorization" column containing a set of "string" type, where > each string is the name of a column (or column:key) whose contents > are to be compared against 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 for the action to > be > considered authorized. > > - An "insert_delete" column of type boolean. If true, insertions > are allowed by any client and deletions are allowed for rows > meeting the authorization requirement. > > - An "update" column of type "set of strings". Each string is the > name of a column (or column:key) for which modification is allowed > in rows meeting the authorization requirement. > > For the current implementation of the OVN_Southbound schema, these tables > would have the following contents: > > RBAC_Roles: > name: "controller" > permissions: "Chassis": <UUID of Chassis row in RBAC_Permissions>, > "Encap": <UUID of Encap row in RBAC_Permissions>, > "Port_Binding":<UUID of Port_Binding row in > RBAC_Permissions>, > "MAC_Binding": <UUID of MAC_Binding row in > RBAC_Permissions> > > RBAC_Permissions: > Chassis row: > authorization: "chassis" > insert_delete: "true" > update: "nb_cfg", "external_ids", "encaps", > "vtep_logical_switches" > Modification of these columns is allowed for rows > which in > which the authorization check passes. > > Encap row: > authorization: "chassis" New column containing CN ID of row creator. > insert_delete: "true" > update: "type", "options", "ip" > > Port_Binding row: > authorization: "" All chassis are authorized. In a recent > live migration proposal, this column would contain > "options:chassis" and "options:migration- > destination". > insert_delete: "false" > update: "chassis" > > MAC_Binding row: > authorization: "" All chassis are allowed to update/delete any row. > Long- term plan would be to eliminate this table. > insert_delete: "true" > update: "logical_port", "ip", "mac", "datapath" > > 4) Implementation logic: > - Extract CN ID from client certificate and store with session state > when remote connection is established. > - Modify ovsdb_execute_{insert,delete,update,mutate} and related > functions > to pass the client session state (need to know whether RBAC is enabled > for the session and client ID for the session). > - Modify ovsdb_execute_{insert,delete,update,mutate} to apply access > controls. > - Logging, statistics. > - Unit tests. > - Documentation. > > Open questions: > 1) Is "list of columns/column:keys" with implied boolean OR sufficient, > or do we need something more powerful (e.g. a mini-language supporting > comparison/boolean/set/... operations). > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
