Open Stack

The way I see it architecturally, the only way that Kerberos will work in
an openstack deployment is to have a KDC installed along side the rest of
the supporting infrastructure.

Kerberos requires FQDNs and therefore you will need it sitting behind any
nat.

That Kerberos should have a trust back to AD.

Architecturally that's the only way that makes any sense all.

One possible mitigating deployment strategy to satisfy anal security teams
may be to deploy one of those new read only domain managers windows 2008
has into the openstack environment.

That would provide a read only KDC.

Not sure that has any impact on the solutions mentioned.  From my
experience it does not.

What I had envisioned originally was passing keystone auth tokens inside of
kerberos ticket comment fields.

I know that MS loves to use that field... but zeroing that data may be to
our benefit if we can as MS AD comment field length can exceed existing
Kerb5 ticket specs and cause damage.  Also having the auth token in a
readily identifiable location in the ticket makes it easy to work with.

Maybe I was looking at it backwards.  Maybe what I really want is a comment
field inside of keystone API for querying the ticket.

I figure any which way you do it, keystone will need to query against the
AD kdc and a ticket will be issued.  We just need to trap it and put it
somewhere useful.

In a similar fashion we probably want the kdc somewhere useful as well.

-Matt


On Tue, Jul 17, 2012 at 2:34 PM, Adam Young <ayoung at redhat.com> wrote:

> On 07/17/2012 05:22 PM, Adam Young wrote:
>
>> For Kerberos, I would suggest the following:
>>
>> 1.  Run Keystone in Apache HTTP with mod_auth_kerberos.  It can fall back
>> to userID/password.
>> 2.  Modify the authentication mechanisms so that it checks REMOTE_USER
>> the same way it currently checks USERID/password when providing a token
>>
>> Cross realm trust is a nice-to-have,  but I suspect that it is not up to
>> Keystone to implement, but rather something that needs to be set up
>> correctly Kerberos wise.  Once Kerberos Auth works, cross realm should
>> work, too.
>>
>>
>> ______________________________**_________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.**openstack.org<OpenStack-operators at lists.openstack.org>
>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
>> openstack-operators<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>>
> As far as using the Kerberos ticket in place of the Keystone tokens, the
> issue is that the other services (Glance, Nova etc) are running in eventlet
> as well, and thus Kerberos support would need to be ported upstream.  This
> is non-trivial, as the Kerberos API is native, which means the GIL will
> kick in.  (Reimplementing Kerberos in Python is not a viable option).  The
> GIL might not be a show stopper, but I wouldn't want to count on it. It
> does mean some native extension would be needed, though.  I am just not
> sure it is worth putting the effort into that.
>
> If all of the service can be run in Apache HTTPD,  you could, in theory,
> replace the auth_token middleware with a new middleware
> auth_service_ticket, that again would just check for the REMOTE_USER value.
>  You would still need to make a call back to Keystone in order to get
> Tenant/Project info.  in addition,  you could not pass on the service
> ticket the way that you do the tokens, so Horizon talking to  Nova and
> Glance would not work without something like TGT forwarding, which I don't
> think we would want to do, either.  So I think, shortish term,  using the
> Kerberos credentials to get the Token is still the right approach.  I'd be
> interesting in  hearing a counter argument.
>
>
>
> ______________________________**_________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.**openstack.org<OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**
> openstack-operators<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20120717/98dd0abf/attachment.html>