keystone admin endpoint not configured with ssl

Bug #1639996 reported by Graeme Gillies on 2016-11-08
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tripleo
High
Juan Antonio Osorio Robles

Bug Description

Hi,

When deploying an overcloud using RDO Newton TripleO, I have the following set in an environment file

parameter_defaults:
  ServiceNetMap:
    KeystoneAdminApiNetwork: external

And I am deploying the overcloud with ssl enabled.

Everything looks correct, the keystone adminurl endpoint is deployed on the external interface, but ssl is not enabled

$ openstack endpoint list
+----------------------------------+-----------+--------------+----------------+
| ID | Region | Service Name | Service Type |
+----------------------------------+-----------+--------------+----------------+
| d6f09efcfee1498db3e27812928ecd9e | regionOne | nova | compute |
| 2eb2a73c07f3401a8c55bb52d5e16428 | regionOne | heat | orchestration |
| 4ef8b17b94954b3cb6b6acf99acfe26d | regionOne | gnocchi | metric |
| f9eac3efb6d143bd94a3c93b988b0979 | RegionOne | heat-cfn | cloudformation |
| d20269db7eec4e1abab2e85fed78b3d2 | regionOne | swift | object-store |
| c76ebdc497a74f948c034961b748cfff | regionOne | heat-cfn | cloudformation |
| 95027035bbe04cb99377d3513149af9d | regionOne | glance | image |
| 0b68b0ca2fb4452785921dd523c55828 | regionOne | cinderv2 | volumev2 |
| 2170658fbed84966a73cc6467242d6bf | regionOne | neutron | network |
| 6cebaed704124836ba895a38ee09f405 | regionOne | aodh | alarming |
| c13aab23ca844f8c90e3261944952ee1 | regionOne | keystone | identity |
| e3b0c12428034ee5a9768386f9f6a8c3 | regionOne | cinderv3 | volumev3 |
| f519d0afafaf47ce9e08b66bc278720b | regionOne | cinder | volume |
| 7243f2c080d3459dac61d04c9f022650 | regionOne | ceilometer | metering |
+----------------------------------+-----------+--------------+----------------+
[stack@rhosops-test-tripleo openstack-deployment]$ openstack endpoint show keystone
+--------------+---------------------------------------------------------------+
| Field | Value |
+--------------+---------------------------------------------------------------+
| adminurl | http://10.8.208.1:35357/v2.0 |
| enabled | True |
| id | c13aab23ca844f8c90e3261944952ee1 |
| internalurl | http://172.16.0.2:5000/v2.0 |
| publicurl | https://cloud.rhosops-test.lab.eng.rdu2.redhat.com:13000/v2.0 |
| region | regionOne |
| service_id | d5e529a0d86b445bb606d9e8caa31ef9 |
| service_name | keystone |
| service_type | identity |
+--------------+---------------------------------------------------------------+

Note the difference between publicurl and adminurl.

While I understand normally this endpoint is deployed in an internal network, considering this endpoint is the most critical to the entire Openstack environment (from a security perspective) we should always enable it with SSL when the cloud has SSL turned on as part of the deployment

Regards,

Graeme

information type: Private Security → Public Security
Changed in tripleo:
status: New → Triaged
importance: Undecided → High
milestone: none → pike-1
Emilien Macchi (emilienm) wrote :

Mhh, it seems like this bug was a feature we did in Ocata, with TLS everywhere and this thing is not backportable... I wonder how we could fix it in Newton though.

Alex Schultz (alex-schultz) wrote :

My understanding is that the admin url should be isolated on an internal management network and not something that would traditionally be exposed externally such that it would require SSL in this case. If you search the bugs around admin url vs public url this seems to be the prevailing upstream response. I'm not sure this is technically a valid bug?

Doesn't matter what network you put it on, the most critically important endpoint in the entire system should be the *first* to have ssl encryption, not the last. It's about making sure the admin password to *your entire openstack installation* is not sent over the wire unencrypted.

Ben Nemec (bnemec) wrote :

This should be fixed by https://review.openstack.org/#/c/426348 but we're not sure how that will behave in the DNS endpoint case. It's a non-trivial environment to set up so I haven't had a chance to do so yet.

Note that we're already deploying an SSL endpoint for keystone admin, we just weren't configuring the endpoint map to point at it.

Changed in tripleo:
milestone: pike-1 → pike-2
Changed in tripleo:
milestone: pike-2 → pike-3
Changed in tripleo:
status: Triaged → In Progress
Changed in tripleo:
milestone: pike-3 → pike-rc1
Changed in tripleo:
assignee: nobody → Ben Nemec (bnemec)
Changed in tripleo:
assignee: Ben Nemec (bnemec) → Juan Antonio Osorio Robles (juan-osorio-robles)

Reviewed: https://review.openstack.org/493937
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=5222b8d920d5b5b2e87004c10808b6bea597720a
Submitter: Jenkins
Branch: master

commit 5222b8d920d5b5b2e87004c10808b6bea597720a
Author: Juan Antonio Osorio Robles <email address hidden>
Date: Tue Aug 15 19:02:42 2017 +0300

    Remove extra keystone admin haproxy listen and allow TLS

    The current code exposes an unused public listen directive in HAProxy
    for the keystone admin endpoint. This is not ideal and should be
    removed, as it exposes the service unnecessarily. We should stick to
    just exposing it to the ctlplane network as is the default.

    If folks really need to expose it to the public network, they can do so
    by modifying the ServiceNetMap through t-h-t and setting the keystone
    admin endpoint's network to external.

    Now, for "single" or "internal" haproxy endpoints, this adds the ability
    to detect if they're using the external network, and thus use TLS on it.
    Which is something a deployer would want if they exposed the keystone
    admin endpoint in such a way.

    Change-Id: I79563f62fd49a4f7654779157ebda3c239d6dd22
    Closes-Bug: #1710909
    Closes-Bug: #1639996

Changed in tripleo:
status: In Progress → Fix Released

This issue was fixed in the openstack/puppet-tripleo 7.3.0 release.

Change abandoned by Ben Nemec (<email address hidden>) on branch: master
Review: https://review.openstack.org/426348
Reason: Fixed a different way by https://review.openstack.org/493937

Reviewed: https://review.openstack.org/494947
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=673c45e789a6947856540cfca2771851f3b1d0aa
Submitter: Jenkins
Branch: stable/ocata

commit 673c45e789a6947856540cfca2771851f3b1d0aa
Author: Juan Antonio Osorio Robles <email address hidden>
Date: Tue Aug 15 19:02:42 2017 +0300

    Remove extra keystone admin haproxy listen and allow TLS

    The current code exposes an unused public listen directive in HAProxy
    for the keystone admin endpoint. This is not ideal and should be
    removed, as it exposes the service unnecessarily. We should stick to
    just exposing it to the ctlplane network as is the default.

    If folks really need to expose it to the public network, they can do so
    by modifying the ServiceNetMap through t-h-t and setting the keystone
    admin endpoint's network to external.

    Now, for "single" or "internal" haproxy endpoints, this adds the ability
    to detect if they're using the external network, and thus use TLS on it.
    Which is something a deployer would want if they exposed the keystone
    admin endpoint in such a way.

    Conflicts:
     manifests/haproxy.pp

    Change-Id: I79563f62fd49a4f7654779157ebda3c239d6dd22
    Closes-Bug: #1710909
    Closes-Bug: #1639996
    (cherry picked from commit 5222b8d920d5b5b2e87004c10808b6bea597720a)

tags: added: in-stable-ocata

This issue was fixed in the openstack/puppet-tripleo 6.5.3 release.

Reviewed: https://review.openstack.org/510738
Committed: https://git.openstack.org/cgit/openstack/puppet-tripleo/commit/?id=4d6fb86be4dac27acf82e4e3eb3397cd8f9686ff
Submitter: Jenkins
Branch: stable/newton

commit 4d6fb86be4dac27acf82e4e3eb3397cd8f9686ff
Author: Juan Antonio Osorio Robles <email address hidden>
Date: Tue Aug 15 19:02:42 2017 +0300

    Remove extra keystone admin haproxy listen and allow TLS

    The current code exposes an unused public listen directive in HAProxy
    for the keystone admin endpoint. This is not ideal and should be
    removed, as it exposes the service unnecessarily. We should stick to
    just exposing it to the ctlplane network as is the default.

    If folks really need to expose it to the public network, they can do so
    by modifying the ServiceNetMap through t-h-t and setting the keystone
    admin endpoint's network to external.

    Now, for "single" or "internal" haproxy endpoints, this adds the ability
    to detect if they're using the external network, and thus use TLS on it.
    Which is something a deployer would want if they exposed the keystone
    admin endpoint in such a way.

    Conflicts:
     manifests/haproxy.pp
     manifests/haproxy/endpoint.pp

    (cherry picked from commit 5222b8d920d5b5b2e87004c10808b6bea597720a)
    (cherry picked from commit 673c45e789a6947856540cfca2771851f3b1d0aa)

    Change-Id: I79563f62fd49a4f7654779157ebda3c239d6dd22
    Closes-Bug: #1710909
    Closes-Bug: #1639996

tags: added: in-stable-newton

This issue was fixed in the openstack/puppet-tripleo 5.6.4 release.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers