Re: [openstack-dev] SSL in Common client
Chmouel Boudjnah wrote: Rob Crittenden writes: From what I found nothing has changed either upstream or in swift. If you are asking about the ability to disable SSL compression it is up to the OS to provide that so nothing was added when we changed swiftclient to requests. Most modern OSes have SSL compression by default, only Debian stable was still enabling it. The only feature that was left behind when we ported swiftclient to requests was the support of Expects (100-Continue) which is referenced upstream in this bug : https://github.com/kennethreitz/requests/issues/713 and it does not seem be trivial to add to requests Yes, that was my take as well. I didn't mean to come across as criticizing the swift client. I was just trying to outline the current state of things. rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SSL in Common client
Chmouel Boudjnah writes: > Most modern OSes have SSL compression by default, only Debian stable was > still enabling it. I mean "have SSL compression *disabled* by default". Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SSL in Common client
Rob Crittenden writes: > From what I found nothing has changed either upstream or in swift. If you are asking about the ability to disable SSL compression it is up to the OS to provide that so nothing was added when we changed swiftclient to requests. Most modern OSes have SSL compression by default, only Debian stable was still enabling it. The only feature that was left behind when we ported swiftclient to requests was the support of Expects (100-Continue) which is referenced upstream in this bug : https://github.com/kennethreitz/requests/issues/713 and it does not seem be trivial to add to requests Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SSL in Common client
Dean Troyer wrote: On Fri, May 2, 2014 at 2:06 PM, Rob Crittenden mailto:rcrit...@redhat.com>> wrote: I'm trying to get devstack to the point where it can configure all the services with SSL so it can be be part of the acceptance process. This is for client communication, there is no expectation that anyone would deploy native SSL endpoints. For the most part things just work. Most of the issues I've run into are server to server communication relating to passing in the CA certificate path. FWIW, DevStack has had the ability to do TLS termination using stud for all public API services, long before any of the individual service SSL/TLS configurations were usable. Using an external TLS termination solves the internal communication problem as long as internal services are configured properly. It also more closely matches what I have seen in real-world deployments. I'm not particularly worried about the endpoints. What I want to test are servers acting as clients and the CLI clients to secure endpoints. I want to ensure that SSL works for those cases where services are running on separate nodes, however they are secured (natively or with a proxy). It has been a while since I've tested this and it is likely to need some love. The basic structure, including building a root and intermediate CA to issue certs that look like real-world certs, has been present for almost a year and a half. I found the basic SSL code in pretty good shape so I suspect that it still works. rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SSL in Common client
Dean Troyer wrote: On Fri, May 2, 2014 at 2:14 PM, Adam Young mailto:ayo...@redhat.com>> wrote: Did swift leave this behind when they switched to Requests? Swift and Glance clients were not changed to requests when I did the initial work in the fall of 2012 due to their use of chunked transfers. I've not really looked into this since then but do recall talk about being able to either implement the required changes in upstream requests or somehow hack it in from below. From what I found nothing has changed either upstream or in swift. rob ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SSL in Common client
On Fri, May 2, 2014 at 2:06 PM, Rob Crittenden wrote: > I'm trying to get devstack to the point where it can configure all the > services with SSL so it can be be part of the acceptance process. This is > for client communication, there is no expectation that anyone would deploy > native SSL endpoints. For the most part things just work. Most of the > issues I've run into are server to server communication relating to passing > in the CA certificate path. > FWIW, DevStack has had the ability to do TLS termination using stud for all public API services, long before any of the individual service SSL/TLS configurations were usable. Using an external TLS termination solves the internal communication problem as long as internal services are configured properly. It also more closely matches what I have seen in real-world deployments. It has been a while since I've tested this and it is likely to need some love. The basic structure, including building a root and intermediate CA to issue certs that look like real-world certs, has been present for almost a year and a half. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SSL in Common client
On Fri, May 2, 2014 at 2:14 PM, Adam Young wrote: > > Did swift leave this behind when they switched to Requests? Swift and Glance clients were not changed to requests when I did the initial work in the fall of 2012 due to their use of chunked transfers. I've not really looked into this since then but do recall talk about being able to either implement the required changes in upstream requests or somehow hack it in from below. dt -- Dean Troyer dtro...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] SSL in Common client
On 05/02/2014 03:06 PM, Rob Crittenden wrote:
TL;DR
Work is happening on a unified client library. This provides the
opportunity to rework the way SSL options are handled. Can we discuss
this in one of the sessions at the Atlanta Summit in a few weeks?
Good survey, thanks.
https://blueprints.launchpad.net/oslo/+spec/common-client-library-2
outlines a path to a common client library in OpenStack. It is still a
work-in-progress though most projects have some amount included
already in openstack/common/apiclient
If you have some time and aren't familiar with this project, this
thread will bring you up to speed:
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024441.html
Parallel to this effort was
https://wiki.openstack.org/wiki/SecureClientConnections which outlined
an effort to replace httplib{2} with requests which is mostly complete
with the exception of neutronclient and glanceclient which still use
httplib.
I'm trying to get devstack to the point where it can configure all the
services with SSL so it can be be part of the acceptance process. This
is for client communication, there is no expectation that anyone would
deploy native SSL endpoints. For the most part things just work. Most
of the issues I've run into are server to server communication
relating to passing in the CA certificate path.
This leads to two interrelated questions:
1. Given the common client, how much should be done in the interim to
clean things up?
2. How will configuration options be handled for server to server
communication?
Right now each project has its own local copy of the common client but
only exceptions are being used. Is there any guess on how soon the
common HTTP client can be in place? This may drive how much effort is
expended trying to clean up the existing client code.
There are significant, probably well-known differences between the
clients, and in the options available to clients used within several
servers to communicate as clients to other servers (e.g. nova to glance).
Here is a brief taste of what I'm talking about:
heatclient defines get_system_ca_file() which will use the system
bundle as a fallback. It is the only client project that does this.
I like this. We should probably use it in Keystone.
Heat seems to have the most expansive set of configuration options,
providing a global clients section and service-specific
clients_ set of options. See
https://github.com/openstack/heat/blob/master/etc/heat/heat.conf.sample#L589
. It was suggested that this be considered for nova as well.
Not surprised they have the best perspective, since they talk to just
about every other service.
The nova team is working to consolidate the available CA options into
a single one in https://bugs.launchpad.net/nova/+bug/1299841 but
leaves behind the separate options for insecure connections.
Disabling SSL compression is important to swift and glance and their
clients provide a way to disable it, and each server that calls these
typically have configuration options to manage it (why there are even
options is unclear since the glance and swift server teams really want
this disabled).
Did swift leave this behind when they switched to Requests?
How SSL is handled in the configuration files is separate from the
Common Client blueprint. Will there continue to be separate options
for insecure, ssl_compression and ca_certificates or will there be a
single, common option set somewhere, or a mixed bag?
How flexible do the CA certificates need to be? Given the distributed
nature of OpenStack, and the fact that some endpoints may be internal
and others external facing, it might seem reasonable to have separate
options for each service. It is also confusing and repetitive. The
heatclient get_system_ca_file() seems to be the way to go, along with
an override in the service configuration file.
That doesn't really handle compression or insecure though, which still
probably need to be per-service.
I think the heat/heatclient approach is the best, coupled with good
defaults in the common client. I think it should look like:
Common client:
ca_certificates = get_system_ca_file()
insecure = False
ssl_compression = False
Ideally the system CA is configured correctly so there is nothing to
do in the client except pass in a https endpoint.
Each server uses the heat method and defines:
[ client ] (most likely always empty)
[ client_ ]
I see are three possible options
ca_certificates_file = /path/to/file
insecure = Boolean
ssl_compression = Boolean
This is the most flexible setup but how one documents it without
confusing people I'm not entirely sure. I think the sample
configuration files should have the entire sections commented out, and
heavily, that these are for overrides only, and only when needed.
Backwards compatibility will be an issue, though the old options can
be deprecated and eventually removed. Or a script
[openstack-dev] SSL in Common client
TL;DR
Work is happening on a unified client library. This provides the
opportunity to rework the way SSL options are handled. Can we discuss
this in one of the sessions at the Atlanta Summit in a few weeks?
https://blueprints.launchpad.net/oslo/+spec/common-client-library-2
outlines a path to a common client library in OpenStack. It is still a
work-in-progress though most projects have some amount included already
in openstack/common/apiclient
If you have some time and aren't familiar with this project, this thread
will bring you up to speed:
http://lists.openstack.org/pipermail/openstack-dev/2014-January/024441.html
Parallel to this effort was
https://wiki.openstack.org/wiki/SecureClientConnections which outlined
an effort to replace httplib{2} with requests which is mostly complete
with the exception of neutronclient and glanceclient which still use
httplib.
I'm trying to get devstack to the point where it can configure all the
services with SSL so it can be be part of the acceptance process. This
is for client communication, there is no expectation that anyone would
deploy native SSL endpoints. For the most part things just work. Most of
the issues I've run into are server to server communication relating to
passing in the CA certificate path.
This leads to two interrelated questions:
1. Given the common client, how much should be done in the interim to
clean things up?
2. How will configuration options be handled for server to server
communication?
Right now each project has its own local copy of the common client but
only exceptions are being used. Is there any guess on how soon the
common HTTP client can be in place? This may drive how much effort is
expended trying to clean up the existing client code.
There are significant, probably well-known differences between the
clients, and in the options available to clients used within several
servers to communicate as clients to other servers (e.g. nova to glance).
Here is a brief taste of what I'm talking about:
heatclient defines get_system_ca_file() which will use the system bundle
as a fallback. It is the only client project that does this.
Heat seems to have the most expansive set of configuration options,
providing a global clients section and service-specific
clients_ set of options. See
https://github.com/openstack/heat/blob/master/etc/heat/heat.conf.sample#L589
. It was suggested that this be considered for nova as well.
The nova team is working to consolidate the available CA options into a
single one in https://bugs.launchpad.net/nova/+bug/1299841 but leaves
behind the separate options for insecure connections.
Disabling SSL compression is important to swift and glance and their
clients provide a way to disable it, and each server that calls these
typically have configuration options to manage it (why there are even
options is unclear since the glance and swift server teams really want
this disabled).
How SSL is handled in the configuration files is separate from the
Common Client blueprint. Will there continue to be separate options for
insecure, ssl_compression and ca_certificates or will there be a single,
common option set somewhere, or a mixed bag?
How flexible do the CA certificates need to be? Given the distributed
nature of OpenStack, and the fact that some endpoints may be internal
and others external facing, it might seem reasonable to have separate
options for each service. It is also confusing and repetitive. The
heatclient get_system_ca_file() seems to be the way to go, along with an
override in the service configuration file.
That doesn't really handle compression or insecure though, which still
probably need to be per-service.
I think the heat/heatclient approach is the best, coupled with good
defaults in the common client. I think it should look like:
Common client:
ca_certificates = get_system_ca_file()
insecure = False
ssl_compression = False
Ideally the system CA is configured correctly so there is nothing to do
in the client except pass in a https endpoint.
Each server uses the heat method and defines:
[ client ] (most likely always empty)
[ client_ ]
I see are three possible options
ca_certificates_file = /path/to/file
insecure = Boolean
ssl_compression = Boolean
This is the most flexible setup but how one documents it without
confusing people I'm not entirely sure. I think the sample configuration
files should have the entire sections commented out, and heavily, that
these are for overrides only, and only when needed.
Backwards compatibility will be an issue, though the old options can be
deprecated and eventually removed. Or a script can probably be used to
migrate options to the new format.
rob
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
