[openstack-dev] [Horizon][Keystone]Re: Keystone 'adminURL' option to fallback to 'internalURL' within Horizon api/keystone.py?

Dolph Mathews dolph.mathews at gmail.com
Fri Apr 8 15:55:36 UTC 2016


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.

The details are buried in API documentation (and perhaps history), but I
tried to summarize the intended design here as I understand it:

  http://dolphm.com/openstack-keystone-service-catalog/

On Thu, Apr 7, 2016 at 1:39 PM, Brad Pokorny <Brad_Pokorny at symantec.com>
wrote:

> Hi Brian,
>
> Copying to the general list, as this is something I've wondered about, and
> others probably are as well.
>
> Please see below. I'm not an expert on this topic, but I've looked at it a
> little bit.
>
> On 4/7/16, 11:02 AM, "Tully, Brian" <brian.tully at hpe.com> wrote:
>
> >Hi there -
> >
> >I'm reaching out to ask for some clarification on what the difference is
> >between adminURL and internalURL as it pertains to the keystoneclient ‹
> >specifically in api/keystone.py
> >(
> http://git.openstack.org/cgit/openstack/horizon/tree/openstack_dashboard/
> >a
> >pi/keystone.py#n163) whereby if the user is logged in as an admin, the api
> >will specify 'adminURL' as the endpoint type.
> >
> >We have a scenario where our admin interface and internal interface are on
> >2 separate networks, and therefore the adminURL is not accessible by
> >Horizon.
>
> I think the original intent of having separate URL types was this exact
> purpose - having them on different networks/ports that can be locked down
> to protect admin operations. This was briefly mentioned in a recent ML
> post:
> http://openstack.markmail.org/message/2in7yab2jvvptg3h?q=%5Bkeystone%5D+ord
> er:date-backward&page=1
>
> It sounds like operations were locked down for the v2 identity API, but
> maybe not for v3 (which I'm assuming is what you're using).
>
> >When using the openstack CLI, we can specify the endpoint type as
> >internal and do not see any perceived reduction in functionality as an
> >admin user.
>
> If everything can be done via the CLI with the internal URL anyway, then
> what's the point of protecting the admin URL on a separate network? Sounds
> like this is what your question below is getting at.
>
> >Are there certain functions that can only be accessed through
> >the adminURL?
>
> This is what I'm not sure of.
>
> >
> >
> >For our use case, we think we can workaround this by adding a new config
> >setting, e.g., IDENTITY_ADMIN_ENDPOINT_TYPE and setting it to
> >'internalURL' in local_settings.py:
> >
> ># IDENTITY_ADMIN_ENDPOINT_TYPE specifies the admin endpoint type to use in
> >the
> ># case that the default admin interface in the Keystone service catalog
> ># is not accessible by Horizon. Use this setting when Horizon cannot
> ># access the identity endpoint at the default 'adminURL' and set it to
> ># 'internalURL'.
> >#IDENTITY_ADMIN_ENDPOINT_TYPE = "internalURL"
> >
> >
> >then in api/keystone.py we can change
> >
> >endpoint_type = 'adminURL'
> >
> >to
> >
> >        endpoint_type = getattr(settings,
> >                                'IDENTITY_ADMIN_ENDPOINT_TYPE',
> >                                'adminURL')
> >
> >which will use 'adminURL' as the default, but allow user customizable
> >endpoint type for identity
> >
> >
> >Does this seem even remotely useful upstream? Let me know...
>
> I would think if the internal URL can do everything the admin URL can do,
> and if that's how things are supposed to remain long term, there's no
> reason to have internal and admin on separate networks.
>
> >
> >Thanks!
> >
> >Brian Tully
> >Software Engineer
> >HPE
> >
> >
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160408/cc8e5d88/attachment.html>


More information about the OpenStack-dev mailing list