Bug 1415175

Summary: Keystone InternalURL endpoint is unusable
Product: Red Hat OpenStack Reporter: Benjamin Schmaus <bschmaus>
Component: openstack-keystoneAssignee: John Dennis <jdennis>
Status: CLOSED CURRENTRELEASE QA Contact: nlevinki <nlevinki>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 9.0 (Mitaka)CC: jdennis, nkinder, panbalag, srevivo
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-06-21 15:31:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Benjamin Schmaus 2017-01-20 13:11:11 UTC 
Description of problem:

It is typical for our customers to VPN in to their OpenStack environment, and only have access to the private networks in the environment via the VPN.  In these cases, we would like them to use the Internal endpoints.  Due to the Keystone configuration, any requests to the internal identity endpoint are re-directed to the PublicURL.  To get around this, currently our customers have to modify their environment files to set OS_AUTH_URL to the identity endpoint admin URL.  This scenario, while not the preferred solution, works fine along with the endpoint type set to internal.  Things break with this configuration when the customer attempts to use any of the identity functions.

Ideally we would be able to set the auth URL and endpoint type to Internal and have that work successfully.  In the future OSP 10 on, we would also like to take advantage of SSL enabled internal endpoints, which do/will use a different subnet from the Public URLs.


Version-Release number of selected component (if applicable):
OSP9 & OSP10

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 5 Benjamin Schmaus 2017-04-12 12:37:19 UTC 
@John - Is there any information regarding the possibility of fixing this issue?