Open Stack

>> "While it may not be a setup that everyone wants, for some deployers
having a public and internal is important."
To be more precise:
In some deployment based on in the initial directives the operators run
into an issue where the `public and internal named urls in keystone` looked
like a possible solution.

>> "Those deployers do not seem to mind the RFC1918 showing up in the
catalog, "

These deployers either just showing the public interfaces just to the
trusted administrators(/power users) or not aware of the possible risks.


>> "if they're doing point-to-point firewalling (as they should be) the
private addresses should not be considered 'secret'  "

Based on your trust in your network setup , you should also consider
removing the authentication from (for example) mariadb,
because if you really think your services are safe from the public you do
not need it either.

A random example for why this address leakage can be dangerous.:
 - Based on your private address the attacker is able to figure out (or
just better guess) where is your non-openstack openstack backend services
 - One of your backend services has weak or no authentication
 - You have an openstack service which is able to connect to arbitrary
address on user request (connection to the backend is explicitly allowed by
firewall)
 ---> possible one hit exploitation

If you think these were never was in an OpenStack together, think again and
read the CVEs and the
deployment guides and script.

We must not make the task for the crackers easier by exposing internal
information.
The addresses are frequently not dangerous alone, but in an OpenStack sized
thing it
can become very dangerous together with another `minor` issues.

Another randomly picked issue regarding to an internal url expose:
 1. have service which has some internal info which would be useful for
another service
 2. expose the internal data to all users on the API
 3. have different backend where the same filed is confidential by nature

We will run into similar issue again and again if we are not strict about
not
exposing internal info.

Whatever you think you are solving by internal urls,
can be solved in multiple other ways without leaking information, in most
cases
we also does not need to modify an OpenStack service code for solving it.

Because the internal urls are useless for the unprivileged users, they
should
not receive them at all, even tough we might have users who simply do not
care
about this, they will not die if we move to more secure solution.


>
> On Fri, Jul 21, 2017 at 1:37 PM, Giulio Fidente <gfidente at redhat.com
>> <mailto:gfidente at redhat.com>> wrote:
>>
>>     Only a comment about the status in TripleO
>>
>>     On 07/21/2017 12:40 PM, Attila Fazekas wrote:
>>
>>     [...]
>>
>>     > We should seriously consider using names instead of ip address also
>>     > on the devstack gates to avoid people thinking the catalog entries
>>     > meant to be used with ip address and keystone is a replacement for
>> DNS.
>>
>>     this is configurable, you can have names or ips in the keystone
>>     endpoints ... actually you can chose to use names or ips independently
>>     for each service and even for the different endpoints
>>     (Internal/Admin/Public) of the same service
>>
>>     if an operator, like you suggested, configures the DNS to resolve
>>     different IPs for the same name basing on where the request comes
>> from,
>>     then he can use the same 'hostname' for all Public, Admin and Internal
>>     endpoints which I *think* is what you're suggesting
>>
>>     also using names is the default when ssl is enabled
>>
>>     check environments/ssl/tls-endpoints-public-dns.yaml and note how
>>     EndpointMap can resolve to CLOUDNAME or IP_ADDRESS
>>
>>     adding Juan on CC as he did a great work around this and can help
>>     further
>>     --
>>     Giulio Fidente
>>     GPG KEY: 08D733BA
>>
>>
>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> 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/20170725/977c8f91/attachment.html>