The impact of the compromise of a chassis running ovn-controller came
up in a discussion with the developers of a system that could
potentially use OVN. Capture some notes on this issue as a todo item.
Signed-off-by: Russell Bryant <rbry...@redhat.com>
---
ovn/TODO | 38 +++++++++++++++++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/ovn/TODO b/ovn/TODO
index 6f625ce..a48251f 100644
--- a/ovn/TODO
+++ b/ovn/TODO
@@ -6,6 +6,42 @@
Can probably get this from Open_vSwitch database.
+** Security
+
+*** Limiting the impact of a compromised chassis.
+
+ Every instance of ovn-controller has the same full access to the central
+ OVN_Southbound database. This means that a compromised chassis can
+ interfere with the normal operation of the rest of the deployment. Some
+ specific examples include writing to the logical flow table to alter
+ traffic handling or updating the port binding table to claim ports that are
+ actually present on a different chassis. In practice, the compromised host
+ would be fighting against ovn-northd and other instances of ovn-controller
+ that would be trying to restore the correct state. The impact could
include
+ at least temporarily redirecting traffic (so the compromised host could
+ receive traffic that it shouldn't) and potentially a more general denial of
+ service.
+
+ There are different potential improvements to this area. The first would
be
+ to add some sort of ACL scheme to ovsdb-server. A proposal for this should
+ first include an ACL scheme for ovn-controller. An example policy would
+ be to make Logical_Flow read-only. Table-level control is needed, but is
+ not enough. For example, ovn-controller must be able to update the Chassis
+ and Encap tables, but should only be able to modify the rows associated
with
+ that chassis and no others.
+
+ A more complex example is the Port_Binding table. Currently,
ovn-controller
+ is the source of truth of where a port is located. There seems to be no
+ policy that can prevent malicious behavior of a compromised host with this
+ table.
+
+ An alternative scheme for port bindings would be to provide an optional
mode
+ where an external entity controls port bindings and make them read-only to
+ ovn-controller. This is actually how OpenStack works today, for example.
+ The part of OpenStack that manages VMs (Nova) tells the networking
component
+ (Neutron) where a port will be located, as opposed to the networking
+ component discovering it.
+
* ovsdb-server
ovsdb-server should have adequate features for OVN but it probably
@@ -100,4 +136,4 @@
Both ovn-controller and ovn-contorller-vtep should use BFD to
monitor the tunnel liveness. Both ovs-vswitchd schema and
- VTEP schema supports BFD.
\ No newline at end of file
+ VTEP schema supports BFD.
--
2.4.3
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
