Open Stack

I was definitely under the mistaken impression that adminURL was
intended to support public. Thanks for clearing things up.

Is it just a terrible idea to support administrative CRUD over public
networks? It seems like some of the previous talk about decentralizing
user and tenant administration would eventually lead to a feature
request to make adminURL publicly accessible.

(As a bonus, if you're only interested in auth validation, the PKI
token validation seems great for achieving this decentralization.)

On Fri, Dec 14, 2012 at 9:32 AM, Dolph Mathews <dolph.mathews at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>