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 <[email protected]
<mailto:[email protected]>> 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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
