On Tue, Mar 14, 2017 at 5:08 AM, Mickey Spiegel <[email protected]> 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 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
