<div dir="ltr"><div><div><div><div><div>Hi All,<br><br></div>I thought it is already well know fact the endpoint types are there ONLY for historical reasons, today they just exists to confuse the one who tries to deploy OpenStack,<br> but it is considered as a deprecated concept and it will die out sooner or later.<br></div></div><br></div>The keystone v3 API already allows to not define internal or admin endpoints at all.<br></div><div><div><div><div><div><div><br></div><div>I just noticed the current documentation encourages the internal endpoint usage. [1]<br></div><div><br></div><div>Is there anybody here who thinks it is a great idea to show private address to the end users ?<br> Even tough some people might consider this cwe-200, but I hope at least looks bad to everyone.<br><br></div><div>The internal endpoints should not be used for telling internal information to the<br> OpenStack services itself.  We are not putting mariadb and rabbitmq address <br>to the catalog as well, we have config files for that.<br><br></div><div>Ideally the end users should not even know we are using different network paths or not,<br></div><div>so the internalURL entries should not be different addresses than the public one <br>or they should not be defined at all.<br><br></div><div>I hope nobody really thinks the public catalog entries expected to contain ip address instead<br></div><div> of domain names by any best practice guide.<br></div><div><br>We are just using ip address in the catalog for dev/test environment,<br></div><div>but  in an ideal case the identity url should start with https:// ,<br></div><div>and it should continue with a domain name, which have several A and AAAA entry<br> and the certificate wound not be for a self signed private ip address.<br></div><div><br></div><div>Is there anybody who really thinks we are putting  http://<ip address>/.. into the catalog on the gate because it is the best practice ?<br></div><div><br></div>You can configure your DNS server properly [2] or use the /etc/hosts file,<br><div><div>when for some reason you want some nodes to use different ip address <br>for reaching the OpenStack services.<br></div><br></div><div>Keystone does not needs to solve anything there,<br> these issues are solved decodes before OpenStack even existed.<br><br>I cannot take the single internalURL usage as a serious response for `isolated networks` ,<br> because it does not scales when you want divide your network even more.   <br>Adding internal2URL, internal3URL is not a great idea either.<br></div><div><br></div><div>We should seriously consider using names instead of ip address also<br></div><div>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></div><div>Using https likely a bad idea in a regular dev environment,<br></div><div>but I hope we agree sending unencrypted credentials over the wire <br>is not a recommended best practice.<br><br></div><div>Best Regards,<br></div><div>Attila<br></div><div><br><br>[1] <a href="https://docs.openstack.org/security-guide/api-endpoints/api-endpoint-configuration-recommendations.html">https://docs.openstack.org/security-guide/api-endpoints/api-endpoint-configuration-recommendations.html</a><br><br>[2] <a href="https://serverfault.com/questions/332440/dns-bind-how-to-return-a-different-ip-based-on-requests-subnet">https://serverfault.com/questions/332440/dns-bind-how-to-return-a-different-ip-based-on-requests-subnet</a><br></div></div></div></div></div></div></div>