[openstack-dev] [Fuel] SSL for master node API

Stanislaw Bogatkin sbogatkin at mirantis.com
Thu Aug 6 12:15:40 UTC 2015


Hello again,

I heard a questions from team how exactly we will implement SSL for master
node. There is a way how I look it:
1. We implement ability to use SSL in fuel-nailgun-agent (I already created
a patch, it is on review now) and merge it in 7.0 release cycle. Also we
will need to implement SSL ability in other clients (for example, fuel-cli)
2. We save both HTTP and HTTPS on master node, because we need to have
seamless master node upgrade. As long as we have 2 years of release
support, we will need to have both protocols enabled for 2 years. After
that period of time we will disable HTTP completely and continue to use
HTTPS only.
3. For those people, who need to force HTTPS-only before 2 years
expiration, I'll prepare a patch that will disable plain HTTP in nginx on
master node if special key in hiera will be found. Also we will add a note
about this to our documentation and release notes (cause if someone will
decide to force HTTPS, he must to upgrade fuel-nailgun-client on all old
nodes too).

On Tue, Aug 4, 2015 at 5:05 PM, Stanislaw Bogatkin <sbogatkin at mirantis.com>
wrote:

> Seems that second solution is okay.
>
> Sebastian, I'll try to fix it before SCF.
>
> On Tue, Aug 4, 2015 at 4:25 PM, Sebastian Kalinowski <
> skalinowski at mirantis.com> wrote:
>
>> +1 for option 2)
>>
>> But I have a question: how do we fit with this into the scope of Feature
>> Freeze and Soft Code Freeze this week?
>> Any ETAs?
>>
>> 2015-08-04 15:06 GMT+02:00 Vitaly Kramskikh <vkramskikh at mirantis.com>:
>>
>>> FYI: There is Strict-Transport-Security
>>> <https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security> header
>>> which can also be useful here (unless we want to make SSL for master node
>>> optional)
>>>
>>> 2015-08-04 15:07 GMT+03:00 Vladimir Sharshov <vsharshov at mirantis.com>:
>>>
>>>> Hi,
>>>>
>>>> +1 to 2nd solution too.
>>>>
>>>> On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L <eli at mirantis.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> +1 to 2nd solution, in this case old environments will work without
>>>>> additional
>>>>> actions. Agents for new environments, CLI and UI will use SSL.
>>>>> But probably for UI we will have to perform redirect on JS level.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin <
>>>>> sbogatkin at mirantis.com> wrote:
>>>>>
>>>>>> Hi guys,
>>>>>> in overall movement of Fuel to use secure sockets we think about
>>>>>> wrapping master node UI and API calls to SSL. But there are next caveat:
>>>>>>
>>>>>> a) fuel-nailgun-agent cannot work via SSL now and need to be
>>>>>> rewritten a little. But if it will be rewritten in 7.0 and HTTPS on master
>>>>>> node will be forced by default, it will break upgrade from previous
>>>>>> releases to 7.0 due fact that after master node upgrade from 6.1 to 7.0 we
>>>>>> will have HTTPS by default and fuel-nailgun-agent on all environments won't
>>>>>> upgraded, so it won't be able to connect to master node after upgrade. It
>>>>>> breaks seamless upgrade procedure.
>>>>>>
>>>>>> What options I see there:
>>>>>> 1. We can forcedly enable SSL for master node and rewrite clients in
>>>>>> 7.0 to be able to work over it. In release notes for 7.0 we will write
>>>>>> forewarning that clients which want to upgrade master node from previous
>>>>>> releases to 7.0 must also install new fuel-nailgun-agent to all nodes in
>>>>>> all deployed environments.
>>>>>>
>>>>>> 2. We can have both SSL and non-SSL versions enabled by default and
>>>>>> rewrite fuel-nailgun-client in 7.0 such way that it will check SSL
>>>>>> availability and be able to work in plain HTTP for legacy mode. So, for all
>>>>>> new environments SSL will be used by default and for old ones plain HTTP
>>>>>> will continue to work too. Master node upgrade will not be broken in this
>>>>>> case.
>>>>>>
>>>>>> 3. We can do some mixed way by gradually rewrite fuel-nailgun-client,
>>>>>> save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next
>>>>>> releases. It is just postponed version of first clause, so it doesn't seems
>>>>>> valid for me, actually.
>>>>>>
>>>>>> I would be really glad to hear what you think about this. Thank you
>>>>>> in advance.
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>>> Unsubscribe:
>>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Vitaly Kramskikh,
>>> Fuel UI Tech Lead,
>>> Mirantis, Inc.
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150806/62de4591/attachment.html>


More information about the OpenStack-dev mailing list