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" <[email protected]> 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" <[email protected]> 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 >> >> > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
