[ovs-dev] OVN: Compromised Chassis Mitigation

Russell Bryant russell at ovn.org
Tue Mar 14 17:48:55 UTC 2017


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.

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