> 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:
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
