I've been looking in to enabling Kerberos for Horizon. Since Horizon
passes the Users credentials on to Keystone to get a token, Kerberos
requires an additional delegation mechanism. This leads to some
questions about how to handle delegation in the case of Federated Identity.
In Kerberos, the Horizon Django App would get a
<strong>REMOTE_USER</strong> set by the Apache web server.
<strong>REMOTE_USER</strong> by itself is not enough to send to Keystone
to get a token.
Kerberos has a Delegation mechanism called <a
href="http://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/";
title="Setting Up S4U2Proxy with FreeIPA">"Service for User to Proxy"
(abbreviated as S4U2Proxy)</a> which would allow (only) Horizon to get a
service ticket to Keystone on behalf of the user. I am pretty certain we
can make this work without too much effort.
The exposure of a hacked Horizon set up this way would be limited to
those active service tickets in the webserver. Since Kerberos tickets
are typically 8 hours in duration, the hacker would have full access to
Keystone and Keystone only for any use that had logged in in the past 8
hours, or that logged in while the attack was running. Essentially, it
would be the same exposure as the current Horizon model would have; both
ticket duration and token duration are configurable.
If Horizon under Kerberos falls back to a user-id/password mechanism,
the Horizon server could fetch a much more powerful Ticket Granting
Ticket (TGT) for the user and use that to get a service ticket. The
exposure for this is much greater; a successful hacker could
impersonate the user to <em>all</em> services. Unfortunately, business
requirements often demand a fallback to UserID/Password for users with
limited ability to administer their own machines. mod_auth_krb5 provides
a means to use userid and password, and there are form based approaches,
too.
For SAML we would need a comparable delegation mechanism. If Horizon
were authorized to access Keystone on the behalf of the user, and it
provided the original SAML Assertion, we would have the same exposure as
the S4U2Proxy case. SAML assertion are time limited, so the Hacked
Horizon instance would only be able to access Keystone, and only for the
duration of the SAML assertions.
In both cases, the exposure would be better than today using
User-Id/Password to get tokens from Horizon in the deployments when the
tokens have a default lifetime of 12 hours. Whereas as sniffed
password would be usable indefinitely, a stolen assertion or service
ticket would only be usable for the life of the ticket or assertion, and
on so long as the Horizon service itself is still compromised.
The Keystone default token duration has been shortened to one hour, and
a corresponding Service ticket policy would make sense: limit Kerberos
Service tickets or SAML assertions to access Horizon to one hour.
I'm digging into X509 client certificates as well, but there does not
seem to be as clear a story there. I think the short of it is
"theoretically possible" but may be impractical.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
