[openstack-dev] [Keystone] internalAdminURL?

Dolph Mathews dolph.mathews at gmail.com
Fri Dec 14 17:32:45 UTC 2012


Side note -- "service" is an overloaded term here-- I was using it to
contrast with "administrative," not to refer to the clients that are
consuming it on behalf of other web services.

Your impression is entirely accurate.

Background: Identity API v2 defines both a "service API" and "admin API."
The "service API" is architected such that it can be deployed publicly on
the Internet and exposes nothing but auth. The "admin API" is, with one
exception, a superset of the "service API" and also exposes auth validation
and administrative CRUD operations for things like users, tenants, etc. It
was intended to be deployed on a secure network.

So, in terms of the "public", "internal" and "admin" endpoints published in
the service catalog by keystone, the "service API" is expected to be
available as both the "public" and "internal" endpoints. The "admin API"
obviously falls into the "admin" endpoint, which is assumed/implied to be
internal.

You asked about support for an "internal admin" interface type, but that's
exactly what "admin" is intended to be... I wanted to clarify that we
*don't* have a use case for the inverse, "public admin", since (I'm
assuming) you were thinking that's what "admin" was?


-Dolph



On Fri, Dec 14, 2012 at 11:10 AM, Mark Washenberger <
mark.washenberger at markwash.net> wrote:

> Oh, perhaps not? I was under the (hopefully mistaken!) impression that
> keystone administration and service-level actions required use of the
> admin interface. For example, tenant administration and (UUID) token
> validation. I reassured myself that this was the case with some manual
> tests in a devstack deployment, but please let me know if I've made
> some mistake.
>
> Thanks
>
> On Thu, Dec 13, 2012 at 6:00 PM, Dolph Mathews <dolph.mathews at gmail.com>
> wrote:
> > Is there an API that needs to distinguish between "public service" and
> > "public administrative" interfaces? (in addition to "internal service"
> and
> > "internal administrative")
> >
> >
> > -Dolph
> >
> >
> >
> > On Thu, Dec 13, 2012 at 6:50 PM, Mark Washenberger
> > <mark.washenberger at markwash.net> wrote:
> >>
> >> I guess my question then becomes, should we support an external/public
> >> admin use case?
> >>
> >> Thanks!
> >>
> >> On Thu, Dec 13, 2012 at 1:05 PM, Dolph Mathews <dolph.mathews at gmail.com
> >
> >> wrote:
> >> > I think it's meant to be implied that the "admin" endpoint is also
> >> > internal.
> >> >
> >> > auth_token should certainly consume the service catalog (via
> >> > keystoneclient,
> >> > ideally). Moving auth_token into keystoneclient itself was a first
> step
> >> > in
> >> > that direction, IMO.
> >> >
> >> >
> >> > On Thursday, December 13, 2012, Mark Washenberger wrote:
> >> >>
> >> >> Hi keystone folks,
> >> >>
> >> >> When I do keystone help endpoint-create, I see
> >> >>
> >> >>   --publicurl <public-url>
> >> >>                         Public URL endpoint
> >> >>   --adminurl <admin-url>
> >> >>                         Admin URL endpoint
> >> >>   --internalurl <internal-url>
> >> >>                         Internal URL endpoint
> >> >>
> >> >> Is there any reason why we don't support an internal admin use case?
> >> >>
> >> >> If we did, we might be able to make the auth_token middleware use its
> >> >> own service catalog instead of a configured default for validating
> >> >> (uuid) tokens, which I would imagine could help out with some
> deployer
> >> >> migration scenarios.
> >> >>
> >> >> Any thoughts? Should I write up a brief blueprint?
> >> >>
> >> >> markwash
> >> >>
> >> >> _______________________________________________
> >> >> OpenStack-dev mailing list
> >> >> OpenStack-dev at lists.openstack.org
> >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >> >
> >> >
> >> > --
> >> >
> >> > -Dolph
> >> >
> >> > _______________________________________________
> >> > OpenStack-dev mailing list
> >> > OpenStack-dev at lists.openstack.org
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20121214/e335afad/attachment.html>


More information about the OpenStack-dev mailing list