Open Stack

On 07/24/2017 04:23 PM, 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.
> 
> Do we have any good (not just making happy funny dev envs) to keep
> endpoint types ?

First step is stopping to use the word "endpoint_type" - it's 
"interface". Also, "internalURL" is legacy keystone v2, it's "internal"

"admin" interface is a thing that people shouldn't use. It's a holdover 
from a day when keystone did weird things. Nobody else should use it ever.

However, we just ADDED the ability to more intelligently consume 
interface so that public/internal cases can be handled better based on 
use-cases from deployers, so I do not think they're going to go away any 
time in the forseeable future.

For instance, we added the ability to pass a list of interface values to 
keystoneauth's endpoint_filter - and these are also now in the adapter 
options so that the default value for "interface" for nova talking to 
neutron can be ['internal', 'public'] - which says: "please default to 
using the internal interface if one exists, otherwise fall back to the 
public interface"

While it may not be a setup that everyone wants, for some deployers 
having a public and internal is important. I know several clouds have 
deployed completely separate API tiers and registered them as "internal" 
so that they could be assured that service-to-service communications 
worked well even if end-users were hammering the public endpoints. Those 
deployers do not seem to mind the RFC1918 showing up in the catalog, and 
if they're doing point-to-point firewalling (as they should be) the 
private addresses should not be considered 'secret' so there's no real 
problem exposing them in the catalog.


> 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:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>