[ovs-dev] [PATCH 3/3] ovn-ctl: add support for SSL nb/sb db connections
Lance Richardson
lrichard at redhat.com
Thu Dec 8 13:37:48 UTC 2016
> From: "Numan Siddique" <nusiddiq at redhat.com>
> To: "Lance Richardson" <lrichard at redhat.com>
> Cc: "ovs dev" <dev at openvswitch.org>
> Sent: Thursday, December 8, 2016 8:01:07 AM
> Subject: Re: [ovs-dev] [PATCH 3/3] ovn-ctl: add support for SSL nb/sb db connections
>
> On Thu, Dec 1, 2016 at 9:07 PM, Lance Richardson <lrichard at redhat.com>
> wrote:
>
> > Add support for SSL connections to OVN northbound and/or
> > southbound databases.
> >
> > To improve security, the NB and SB ovsdb daemons no longer
> > have open ptcp connections by default. This is a change in
> > behavior from previous versions, users wishing to use TCP
> > connections to the NB/SB daemons can either request that
> > a passive TCP connection be used via ovn-ctl command-line
> > options (e.g. via OVN_CTL_OPTS/OVN_NORTHD_OPTS in startup
> > scripts):
> >
> > --db-sb-default-remote=yes
> > --db-nb-default-remote=yes
> >
> > Or configure a connection after the NB/SB daemons have been
> > started, e.g.:
> >
> > ovn-sbctl set-connection ptcp:6642
> > ovn-nbctl set-connection ptcp:6641
> >
> > Users desiring SSL database connections will need to generate certificates
> > and private key as described in INSTALL.SSL.rst and perform the following
> > one-time configuration steps:
> >
> > ovn-sbctl set-ssl <private-key> <certificate> <ca-cert>
> > ovn-sbctl set-connection pssl:6642
> > ovn-nbctl set-ssl <private-key> <certificate> <ca-cert>
> > ovn-nbctl set-connection pssl:6641
> >
> > On the ovn-controller and ovn-controller-vtep side, SSL configuration
> > must be provided on the command-line when the daemons are started, this
> > should be provided via the following command-line options (e.g. via
> > OVN_CTL_OPTS/OVN_CONTROLLER_OPTS in startup scripts):
> >
> > --ovn-controller-ssl-key=<private-key>
> > --ovn-controller-ssl-cert=<certificate>
> > --ovn-controller-ssl-ca-cert=<ca-cert>
> >
> > The SB database connection should also be configured to use SSL, e.g.:
> >
> > ovs-vsctl set Open_vSwitch . \
> > external-ids:ovn-remote=ssl:w.x.y.z:6642
> >
> > Signed-off-by: Lance Richardson <lrichard at redhat.com>
> > ---
> > NEWS | 5 ++++
> > manpages.mk | 4 +++
> > ovn/utilities/ovn-ctl | 72 ++++++++++++++++++++++++++++++
> > ++++-----------
> > ovn/utilities/ovn-ctl.8.xml | 7 +++++
> > 4 files changed, 71 insertions(+), 17 deletions(-)
> >
> > diff --git a/NEWS b/NEWS
> > index 3a33abf..9ac8808 100644
> > --- a/NEWS
> > +++ b/NEWS
> > @@ -9,6 +9,11 @@ Post-v2.6.0
> > * Support for source IP address based routing.
> > * Support for managing SSL and remote connection configuration in
> > northbound and southbound databases.
> > + * TCP connections to northbound and southbound databases are no
> > + longer enabled by default and must be explicitly configured.
> > + See documentation for ovn-sbctl/ovn-nbctl "set-connection" command
> > + or ovn-ctl "--db-sb-default-remote"/"--db-nb-default-remote"
> > + options for information regarding enabling TCP connections.
> > - Fixed regression in table stats maintenance introduced in OVS
> > 2.3.0, wherein the number of OpenFlow table hits and misses was
> > not accurate.
> > diff --git a/manpages.mk b/manpages.mk
> > index 11ec023..742bd66 100644
> > --- a/manpages.mk
> > +++ b/manpages.mk
> > @@ -10,6 +10,8 @@ ovn/utilities/ovn-sbctl.8: \
> > lib/table.man \
> > lib/vlog.man \
> > ovsdb/remote-active.man \
> > + ovsdb/remote-active.man \
> > + ovsdb/remote-passive.man \
> > ovsdb/remote-passive.man
> > ovn/utilities/ovn-sbctl.8.in:
> > lib/common.man:
> > @@ -20,6 +22,8 @@ lib/ssl.man:
> > lib/table.man:
> > lib/vlog.man:
> > ovsdb/remote-active.man:
> > +ovsdb/remote-active.man:
> > +ovsdb/remote-passive.man:
> > ovsdb/remote-passive.man:
> >
> > ovsdb/ovsdb-client.1: \
> > diff --git a/ovn/utilities/ovn-ctl b/ovn/utilities/ovn-ctl
> > index 73e78e5..4dade90 100755
> > --- a/ovn/utilities/ovn-ctl
> > +++ b/ovn/utilities/ovn-ctl
> > @@ -50,7 +50,7 @@ stop_ovsdb () {
> >
> > demote_ovnnb() {
> > if test ! -z "$DB_NB_SYNC_FROM_ADDR"; then
> > - echo "tcp:$DB_NB_SYNC_FROM_ADDR:$DB_NB_SYNC_FROM_PORT" >
> > $ovnnb_active_conf_file
> > + echo
> > "$DB_NB_SYNC_FROM_PROTO:$DB_NB_SYNC_FROM_ADDR:$DB_NB_SYNC_FROM_PORT"
> > > $ovnnb_active_conf_file
> > fi
> >
> > if test -e $ovnnb_active_conf_file; then
> > @@ -64,7 +64,7 @@ demote_ovnnb() {
> >
> > demote_ovnsb() {
> > if test ! -z "$DB_SB_SYNC_FROM_ADDR"; then
> > - echo "tcp:$DB_SB_SYNC_FROM_ADDR:$DB_SB_SYNC_FROM_PORT" >
> > $ovnsb_active_conf_file
> > + echo
> > "$DB_SB_SYNC_FROM_PROTO:$DB_SB_SYNC_FROM_ADDR:$DB_SB_SYNC_FROM_PORT"
> > > $ovnsb_active_conf_file
> > fi
> >
> > if test -e $ovnsb_active_conf_file; then
> > @@ -93,15 +93,21 @@ start_ovsdb () {
> >
> > set ovsdb-server
> >
> > - set "$@" --detach --monitor $OVN_NB_LOG \
> > - --log-file=$OVN_NB_LOGFILE \
> > - --remote=punix:$DB_NB_SOCK \
> > - --remote=ptcp:$DB_NB_PORT:$DB_NB_ADDR \
> > - --pidfile=$DB_NB_PID \
> > - --unixctl=ovnnb_db.ctl
> > + set "$@" --detach --monitor
> > + set "$@" $OVN_NB_LOG --log-file=$OVN_NB_LOGFILE
> > + set "$@" --remote=punix:$DB_NB_SOCK --pidfile=$DB_NB_PID
> > + set "$@" --remote=db:OVN_Northbound,NB_Global,connections
> > + set "$@" --unixctl=ovnnb_db.ctl
> > + set "$@" --private-key=db:OVN_Northbound,SSL,private_key
> > + set "$@" --certificate=db:OVN_Northbound,SSL,certificate
> > + set "$@" --ca-cert=db:OVN_Northbound,SSL,ca_cert
> > +
> > + if test X"$
> >
> > DB_NB_DEFAULT_REMOTE" = Xyes; then
> > + set "$@" --remote=ptcp:$DB_NB_PORT:$DB_NB_ADDR
> > + fi
> >
>
> You think its good to add the remote defined in $DB_NB_ADDR/$DB_NB_PORT
> into the Connection table by this script if $
>
> DB_NB_DEFAULT_REMOTE
> is set to No.
>
Hi Numan,
This would imply that unauthenticated/insecure remote access to the
NB database is always available.
Users wanting to use SSL for the NB database connection are likely
to be concerned about security and authentication for this connection,
having a default parallel connection path with unrestricted access
would make the use of SSL pointless.
An alternative that would preserve existing behavior would be to
have users needing SSL set e.g. "DB_NB_NO_DEFAULT_REMOTE=yes" in
their environment, but this would be error-prone. It seems better
to err on the side of security by default.
Regards,
Lance
> Some thing like below
>
> #########
> if test X"$DB_NB_DEFAULT_REMOTE" = Xno; then
> ovn-nbctl set-connection "ptcp:$DB_NB_PORT:$DB_NB_ADDR"
> fi
> #########
>
> Thanks
> Numan
>
>
More information about the dev
mailing list