Open Stack

On Mon, Jul 24, 2017 at 10:53 AM, Dmitry Tantsur <dtantsur at redhat.com>
wrote:

> 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).
>

So the question looks like this without tuning:
 - 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 ?


>
> On 07/24/2017 10:23 AM, Attila Fazekas wrote:
>
>> Thanks for your answer.
>>
>> The real question is do we agree in the
>> internalULR usage what suggested in [1] is a bad security practice
>> and should not be told to operators at all.
>>
>> Also we should try to get rid off the enpointTypes in keystone v4.
>>
>
> Let's not seriously talk about keystone v4 at this point, we haven't
> gotten rid of v2 so far.
>
> Eventually it will come, but until that the story told to operators could
be we are going to remove the
interfaces (admin/internal/public) from the keystone catalog.


>
>> Do we have any good (not just making happy funny dev envs) to keep
>> endpoint types ?
>>
>
> 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.
>

The only real question is how many people would mind to use SSL/TLS also
internally
across the  services, when https is the one provided to the end-users.

It does not means the LB to backend needs to be SSL, it can still remain
HTTP regardless to the catalog entry.

If the internal both-way no-SSL communication is really important for the
deployers and we do not
want to change how the keystone API behave we might put
the service urls next to to auth urls in the  keystone_authtoken_section
kind of sections .

Many service has multiple  keystone_authtoken_section [3],
but for example `heat` does not have dedicated auth like section for all
related services.

The options available keystoneauth1 is usually directly exposed to the
service config,
so introducing a `catalog_override` option which accepts a json file can be
the simplest option.

Again, it is only required if you really want to use different protocol
internally than  for the public.
This should not be in a security best practice guide either, but if there
is a real user request for it so be it.


>
> 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.
>
>

If we are speaking about micro optimization, the above way would
open up the way to have services to choose `same host`, `same segment`
service instances
when it makes sense (usually does not).

Most of the networking libraries has built in intelligence to cache DNS
responses,
the dns lookup typically causes extra <0.1ms latency an openstack service
frequently needs
more than 5 ms to respond.

But if you really want to do some micro optimization here,
there are multiple small dns services available which can run on the
localhost and provide faster response
then a remote one and they are also able to hide dns infrastructure
downtimes.

The devstack vms are using unbound for DNS caching.

As always, you can use /etc/hosts file to bypass the DNS lookups,
however the /etc/hosts not expected to do Round Robin, but if you were
happy without DNS
 you will not notice it.

nscd might have surprising changing behavior, but available in all Linux
distros,
likely you want to decrease the negative-time-to-live times in most cases.


[3]
https://docs.openstack.org/ocata/config-reference/shared-file-systems/samples/manila.conf.html


>
>>
>>
>> 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/20170726/64463afa/attachment.html>