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

McLellan, Steven steve.mclellan at hpe.com
Thu Apr 7 19:21:26 UTC 2016


I think Brad's spot on. See inline, but short version - the special case
is only required if the KS catalog returns v2.0 endpoints.

On 4/7/16, 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
>>pi/keystone.py#n163) whereby if the user is logged in as an admin, the
>>will specify 'adminURL' as the endpoint type.
>>We have a scenario where our admin interface and internal interface are
>>2 separate networks, and therefore the adminURL is not accessible by
>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
>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.

Note that the endpoint used will be the one the keystone catalog returns,
not whatever's configured in local_settings, but under v2.0, if instead of
using the admin port on 35357 you use port 5000 you'll get 404s from some
identity management functions:

# V3
curl -H"x-auth-token: $token"
{"user": {"id": "719319cc0f9d47b9b9ce512b77ae5da6", "enabled": true,
"domain_id": "default", "links": {"self":
"name": "admin"}}

# V2.0
curl -H"x-auth-token: $token"
{"error": {"message": "The resource could not be found.", "code": 404,
"title": "Not Found"}}

If the catalog returns v3, this special case isn't needed; if it's v2.0,
it is.

>>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
>># 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'.
>>then in api/keystone.py we can change
>>endpoint_type = 'adminURL'
>>        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.
>>Brian Tully
>>Software Engineer

More information about the OpenStack-dev mailing list