Open Stack

Hi,

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
>>(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+or
>d
>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.



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"
http://192.168.235.128:5000/v3/users/719319cc0f9d47b9b9ce512b77ae5da6
{"user": {"id": "719319cc0f9d47b9b9ce512b77ae5da6", "enabled": true,
"domain_id": "default", "links": {"self":
"http://192.168.235.128:5000/v3/users/719319cc0f9d47b9b9ce512b77ae5da6"},
"name": "admin"}}


# V2.0
curl -H"x-auth-token: $token"
http://192.168.235.128:5000/v2.0/users/719319cc0f9d47b9b9ce512b77ae5da6
{"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
>>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
>>
>>
>