<div dir="ltr">>> "While it may not be a setup that everyone wants, for some deployers having a public and internal is important."<br><div class="gmail_extra"><div class="gmail_quote"><div>To be more precise: <br>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.<br><br></div><div>>> "Those deployers do not seem to mind the RFC1918 showing up in the catalog, "<br></div><div><br>These deployers either just showing the public interfaces just to the trusted administrators(/power users) or not aware of the possible risks.<br><br><br>>> "if they're doing point-to-point firewalling (as they should be) the private addresses should not be considered 'secret' "<br><br></div><div>Based on your trust in your network setup , you should also consider removing the authentication from (for example) mariadb,<br></div><div>because if you really think your services are safe from the public you do not need it either.<br><br></div><div>A random example for why this address leakage can be dangerous.:<br></div><div> - Based on your private address the attacker is able to figure out (or just better guess) where is your non-openstack openstack backend services<br></div><div> - One of your backend services has weak or no authentication<br></div><div> - 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) <br></div><div> ---> possible one hit exploitation<br><br></div><div>If you think these were never was in an OpenStack together, think again and read the CVEs and the<br></div><div>deployment guides and script.<br></div><div><br></div><div>We must not make the task for the crackers easier by exposing internal information.<br></div><div>The addresses are frequently not dangerous alone, but in an OpenStack sized thing it <br></div><div>can become very dangerous together with another `minor` issues.<br></div><div><br></div><div>Another randomly picked issue regarding to an internal url expose:<br></div><div> 1. have service which has some internal info which would be useful for another service<br></div><div> 2. expose the internal data to all users on the API<br></div><div> 3. have different backend where the same filed is confidential by nature<br></div><div><br></div><div>We will run into similar issue again and again if we are not strict about not <br></div><div>exposing internal info.<br><br></div><div>Whatever you think you are solving by internal urls,<br></div><div>can be solved in multiple other ways without leaking information, in most cases<br></div><div>we also does not need to modify an OpenStack service code for solving it.<br></div><div><br></div><div>Because the internal urls are useless for the unprivileged users, they should<br></div><div>not receive them at all, even tough we might have users who simply do not care<br></div><div>about this, they will not die if we move to more secure solution. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
On Fri, Jul 21, 2017 at 1:37 PM, Giulio Fidente <<a href="mailto:gfidente@redhat.com" target="_blank">gfidente@redhat.com</a> <mailto:<a href="mailto:gfidente@redhat.com" target="_blank">gfidente@redhat.com</a>>> wrote:<br>
<br>
Only a comment about the status in TripleO<br>
<br>
On 07/21/2017 12:40 PM, Attila Fazekas wrote:<br>
<br>
[...]<br>
<br>
> We should seriously consider using names instead of ip address also<br>
> on the devstack gates to avoid people thinking the catalog entries<br>
> meant to be used with ip address and keystone is a replacement for DNS.<br>
<br>
this is configurable, you can have names or ips in the keystone<br>
endpoints ... actually you can chose to use names or ips independently<br>
for each service and even for the different endpoints<br>
(Internal/Admin/Public) of the same service<br>
<br>
if an operator, like you suggested, configures the DNS to resolve<br>
different IPs for the same name basing on where the request comes from,<br>
then he can use the same 'hostname' for all Public, Admin and Internal<br>
endpoints which I *think* is what you're suggesting<br>
<br>
also using names is the default when ssl is enabled<br>
<br>
check environments/ssl/tls-endpoints<wbr>-public-dns.yaml and note how<br>
EndpointMap can resolve to CLOUDNAME or IP_ADDRESS<br>
<br>
adding Juan on CC as he did a great work around this and can help<br>
further<br>
--<br>
Giulio Fidente<br>
GPG KEY: 08D733BA<br>
<br>
<br>
<br>
<br></span><span class="gmail-">
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br>
</span></blockquote><div class="gmail-HOEnZb"><div class="gmail-h5">
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>