<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 24, 2017 at 10:53 AM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">These questions are to the operators, and should be asked on openstack-operators IMO (maybe with tuning the overall tone to be a bit less aggressive).<span class="gmail-"><br></span></blockquote><div><br></div><div>So the question looks like this without tuning:<br></div><div> - Do you think is it good idea to spam the users with internal data which useless for them unless they want to use it against you ?<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"><span class="gmail-">
<br>
On 07/24/2017 10:23 AM, Attila Fazekas wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for your answer.<br>
<br>
The real question is do we agree in the<br>
internalULR usage what suggested in [1] is a bad security practice<br>
and should not be told to operators at all.<br>
<br>
Also we should try to get rid off the enpointTypes in keystone v4.<br>
</blockquote>
<br></span>
Let's not seriously talk about keystone v4 at this point, we haven't gotten rid of v2 so far.<span class="gmail-"><br>
<br></span></blockquote><div>Eventually it will come, but until that the story told to operators could be we are going to remove the<br></div><div>interfaces (admin/internal/public) from the keystone catalog. <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"><span class="gmail-">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Do we have any good (not just making happy funny dev envs) to keep<br>
endpoint types ?<br>
</blockquote>
<br></span>
I suspect any external SSL termination proxy. And anything else that will make the URLs exposed to end users look different from ones exposed to services.<br></blockquote><div><br><div>The only real question is how many people would mind to use SSL/TLS also internally<br> across the services, when https is the one provided to the end-users.<br></div><div><br></div><div>It does not means the LB to backend needs to be SSL, it can still remain HTTP regardless to the catalog entry.<br></div><div><br></div><div>If the internal both-way no-SSL communication is really important for the deployers and we do not<br> want to change how the keystone API behave we might put<br></div><div>the service urls next to to auth urls in the keystone_authtoken_section kind of sections .<br><br>Many service has multiple keystone_authtoken_section [3],<br></div><div>but for example `heat` does not have dedicated auth like section for all related services.<br></div><div><br></div><div>The options available keystoneauth1 is usually directly exposed to the service config,<br></div>so introducing a `catalog_override` option which accepts a json file can be the simplest option.<br><br></div><div>Again, it is only required if you really want to use different protocol internally than for the public.<br></div><div>This should not be in a security best practice guide either, but if there is a real user request for it so be it.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Speaking of DNS, I also suspect there may be a micro-optimization in not making the services use it when talking to each other, while still providing names to end users.<br>
<br></blockquote><div><br></div><div><br></div><div>If we are speaking about micro optimization, the above way would<br> open up the way to have services to choose `same host`, `same segment` service instances<br> when it makes sense (usually does not).<br><br></div><div>Most of the networking libraries has built in intelligence to cache DNS responses,<br></div><div>the dns lookup typically causes extra <0.1ms latency an openstack service frequently needs<br> more than 5 ms to respond.<br></div><div><br></div><div>But if you really want to do some micro optimization here,<br></div><div>there are multiple small dns services available which can run on the localhost and provide faster response<br></div><div>then a remote one and they are also able to hide dns infrastructure downtimes.<br></div><div><br>The devstack vms are using unbound for DNS caching.<br></div><div><br></div><div>As always, you can use /etc/hosts file to bypass the DNS lookups,<br></div><div>however the /etc/hosts not expected to do Round Robin, but if you were happy without DNS<br></div><div> you will not notice it.<br> </div><div><br></div><div>nscd might have surprising changing behavior, but available in all Linux distros,<br></div><div>likely you want to decrease the negative-time-to-live times in most cases.</div><div><br></div><div><br>[3] <a href="https://docs.openstack.org/ocata/config-reference/shared-file-systems/samples/manila.conf.html">https://docs.openstack.org/ocata/config-reference/shared-file-systems/samples/manila.conf.html</a><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">
<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-">
<br>
<br>
<br>
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 further<br>
--<br>
Giulio Fidente<br>
GPG KEY: 08D733BA<br>
<br>
<br>
<br>
<br></span>
______________________________<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>
</blockquote>
<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>
</blockquote></div><br></div></div>