<div dir="ltr">You can use the public URL as a fallback to the internal URL; however, the admin URL is assumed to be the only privileged API endpoint.<div><br></div><div>The details are buried in API documentation (and perhaps history), but I tried to summarize the intended design here as I understand it:</div><div><br></div><div>  <a href="http://dolphm.com/openstack-keystone-service-catalog/">http://dolphm.com/openstack-keystone-service-catalog/</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 1:39 PM, Brad Pokorny <span dir="ltr"><<a href="mailto:Brad_Pokorny@symantec.com" target="_blank">Brad_Pokorny@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Brian,<br>
<br>
Copying to the general list, as this is something I've wondered about, and<br>
others probably are as well.<br>
<br>
Please see below. I'm not an expert on this topic, but I've looked at it a<br>
little bit.<br>
<br>
On 4/7/16, 11:02 AM, "Tully, Brian" <<a href="mailto:brian.tully@hpe.com">brian.tully@hpe.com</a>> wrote:<br>
<br>
>Hi there -<br>
><br>
>I'm reaching out to ask for some clarification on what the difference is<br>
>between adminURL and internalURL as it pertains to the keystoneclient ‹<br>
>specifically in api/keystone.py<br>
>(<a href="http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/</a><br>
>a<br>
>pi/keystone.py#n163) whereby if the user is logged in as an admin, the api<br>
>will specify 'adminURL' as the endpoint type.<br>
><br>
>We have a scenario where our admin interface and internal interface are on<br>
>2 separate networks, and therefore the adminURL is not accessible by<br>
>Horizon.<br>
<br>
I think the original intent of having separate URL types was this exact<br>
purpose - having them on different networks/ports that can be locked down<br>
to protect admin operations. This was briefly mentioned in a recent ML<br>
post:<br>
<a href="http://openstack.markmail.org/message/2in7yab2jvvptg3h?q=%5Bkeystone%5D+ord
er:date-backward&page=1" rel="noreferrer" target="_blank">http://openstack.markmail.org/message/2in7yab2jvvptg3h?q=%5Bkeystone%5D+ord<br>
er:date-backward&page=1</a><br>
<br>
It sounds like operations were locked down for the v2 identity API, but<br>
maybe not for v3 (which I'm assuming is what you're using).<br>
<br>
>When using the openstack CLI, we can specify the endpoint type as<br>
>internal and do not see any perceived reduction in functionality as an<br>
>admin user.<br>
<br>
If everything can be done via the CLI with the internal URL anyway, then<br>
what's the point of protecting the admin URL on a separate network? Sounds<br>
like this is what your question below is getting at.<br>
<br>
>Are there certain functions that can only be accessed through<br>
>the adminURL?<br>
<br>
This is what I'm not sure of.<br>
<br>
><br>
><br>
>For our use case, we think we can workaround this by adding a new config<br>
>setting, e.g., IDENTITY_ADMIN_ENDPOINT_TYPE and setting it to<br>
>'internalURL' in local_settings.py:<br>
><br>
># IDENTITY_ADMIN_ENDPOINT_TYPE specifies the admin endpoint type to use in<br>
>the<br>
># case that the default admin interface in the Keystone service catalog<br>
># is not accessible by Horizon. Use this setting when Horizon cannot<br>
># access the identity endpoint at the default 'adminURL' and set it to<br>
># 'internalURL'.<br>
>#IDENTITY_ADMIN_ENDPOINT_TYPE = "internalURL"<br>
><br>
><br>
>then in api/keystone.py we can change<br>
><br>
>endpoint_type = 'adminURL'<br>
><br>
>to<br>
><br>
>        endpoint_type = getattr(settings,<br>
>                                'IDENTITY_ADMIN_ENDPOINT_TYPE',<br>
>                                'adminURL')<br>
><br>
>which will use 'adminURL' as the default, but allow user customizable<br>
>endpoint type for identity<br>
><br>
><br>
>Does this seem even remotely useful upstream? Let me know...<br>
<br>
I would think if the internal URL can do everything the admin URL can do,<br>
and if that's how things are supposed to remain long term, there's no<br>
reason to have internal and admin on separate networks.<br>
<br>
><br>
>Thanks!<br>
><br>
>Brian Tully<br>
>Software Engineer<br>
>HPE<br>
><br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>