[openstack-dev] [Keystone] Trusts and Explicit Impersonation
David Chadwick
d.w.chadwick at kent.ac.uk
Wed Dec 12 08:43:24 UTC 2012
The way a token is bound to a client is already done in both Grids and
SAML federations. Both essentially use the same mechanism. The client
has a key pair, and the client's public key is put inside the token. The
client can then prove to any recipient that it is the rightful owner of
the token by signing the message. The key pair can be semi-permanent (as
in Grids and user certs) or transient (as in SAML holder of key and Grid
proxy certs). The user of the client software (such as a human or
application) does not need to know it has a key pair, as it can be
generated on the fly by the client software and only kept for the
duration of the session.
In comparison, the current Keystone mechanism uses what is known as
bearer tokens, meaning that the token belongs to whoever has it. This is
not a very secure mechanism as you will appreciate, since tokens can be
stolen or used by recipients to masquerade as the original owners, and
recipients have no guarantee that the requestor is the genuine owner.
In my opinion this is a completely separate issue to delegation and
should not be confused with it, since you can have holder of key tokens
with or without delegation
regards
David
On 11/12/2012 18:53, Matt Joyce wrote:
> I think there is a question as to the nature of what is a fully
> qualified cloud instance.
>
> In physical hosting land it was easy enough. Right IP, right DNS
> forwards and reverse, and occasionally some form of signing on top of that.
>
> With cloud there is a fundamentally different environment that promotes
> new needs.
>
> Basically, from my perspective this ties into a basic need. How can a
> service token or user token know that it is executing from the instance
> or tenant it was intended to fire from. Right now it's simple, we don't
> care if it is or isn't. But, we won't survive long before we need to
> address this.
>
> The question becomes, how are we going to sign the tokens that we create
> so as to exist as part of a tenant? or specific to an instance? and
> how will we be sure that those tokens are not going beyond those boundaries.
>
> This I think is important to at least think about before moving
> forward. We're talking about things such as service ticket equivalents,
> and those have traditionally required FQDNs for a reason. But in this
> modern age, an FQDN is no longer going to service our needs. More to
> the point, how will we be able to export service tickets then outside of
> our cloud environment?
>
>
>
> -Matt
>
> On Tue, Dec 11, 2012 at 7:01 AM, Adam Young <ayoung at redhat.com
> <mailto:ayoung at redhat.com>> wrote:
>
> On 12/11/2012 08:06 AM, David Chadwick wrote:
>
> Hi Mark
>
> I am finding it difficult to understand your use case. Can you
> help me please. If Nova is the compute service, then surely it
> is able to upload any images that it wants to, otherwise how can
> they run? Isnt it the case that Nova is the service provider,
> which has a policy that says who is entitled to upload images to
> it? Someone, say the deployer, sets this policy. So say the
> policy is "role X can upload images", then any user who can
> authenticate to Keystone and be assigned role X is able to
> upload images. Doesnt this provide the functionality you need?
>
>
> David, if I understand what he is asking, he only wants Nova to be
> able to upload the images; a user can't upload any old image, just
> the ones somehow gated by Nova. But the image should still be
> owned by the user that triggered the upload.Its an interesting use
> case, but not something we would be able to support in the Grizzly
> time frame, and not something that I would put under explicit
> impersonation, but rather something of the nature of policy
> enforcement. They might be able to do it built on trusts if they
> had a policy that requires the token have the additional value of
> "trustee=nova"
>
>
>
> regards
>
> David
>
>
> On 10/12/2012 21:12, Mark Washenberger wrote:
>
> I must be missing something. Thanks in advance for
> correcting me!
>
>
> Why would the user not have the role?
>
>
> The idea behind this feature is that the user is not
> authorized to
> upload an image, but Nova is authorized to upload an image
> on the
> user's behalf. This feature would not be turned on by
> default, but it
> should be available at a deployer's discretion.
>
> On Mon, Dec 10, 2012 at 12:14 PM, Adam Young
> <ayoung at redhat.com <mailto:ayoung at redhat.com>> wrote:
>
> On 12/10/2012 02:41 PM, Mark Washenberger wrote:
>
>
> So, in the case of this feature, the trustor (end
> user) is going to
> delegate to the trustee (Glance) a role that the
> trustor himself does
> not have? (Namely, some role that allows image
> uploads.) That seems to
> violate the spirit of the the spec.
>
>
> Nope. The user needs to have the role in the first place.
>
> I must be missing something. Thanks in advance for
> correcting me!
>
>
> Why would the user not have the role?
>
>
> markwash
>
> On Mon, Dec 10, 2012 at 10:56 AM, Yee, Guang
> <guang.yee at hp.com <mailto:guang.yee at hp.com>> wrote:
>
>
> I think the current trust BP should cover your
> use case.
>
> http://wiki.openstack.org/__Keystone/Trusts
> <http://wiki.openstack.org/Keystone/Trusts>
>
> In your case, the trustee would be Image Service
> or endpoint.
>
>
> Guang
>
>
> -----Original Message-----
> From: Mark Washenberger
> [mailto:mark.washenberger at __markwash.net
> <mailto:mark.washenberger at markwash.net>]
> Sent: Monday, December 10, 2012 10:36 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] [Keystone] Trusts
> and Explicit Impersonation
>
> David, Adam, (other Trusts/Auth folks. . .),
>
> Any thoughts on this?
>
> Thanks!
>
>
> From: Mark Washenberger
> [mailto:mark.washenberger at __markwash.net
> <mailto:mark.washenberger at markwash.net>]
> Sent: Friday, December 07, 2012 8:53 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] Trusts and
> Explicit Impersonation
>
>
>
> Hi auth guys!
>
>
>
> As we continue to make progress towards
> large service providers
> exposing
> their Glance deployments as public
> services, one critical feature we
> need
>
>
> to
>
>
> support is the ability to limit certain
> actions (mostly image uploads,
>
>
> also
>
>
> possibly image downloads) to use by Nova
> or other trusted services, and
> restrict users from taking those actions
> directly. Of course, this
>
>
> feature
>
>
> would only be turned on by
> configuration, and not likely by default.
>
>
>
> I had figured we could do this using
> some features piggy-backed on
> keystone pki, and documented the use
> case in this blueprint:
>
>
> https://blueprints.launchpad.__net/keystone/+spec/keystone-__explicit-impersonat
> <https://blueprints.launchpad.net/keystone/+spec/keystone-explicit-impersonat>
>
> ion
>
>
>
>
> I've been following the discussion of
> Keystone Trusts with interest,
> and
> some questions have presented
> themselves. Is there some way we could
> manipulate the Trust mechanism to
> provide the auth feature Glance
> needs?
> Another (scarier for me) question: does
> the Trusts proposal conflict
> with
>
>
> my
>
>
> feature request?
>
>
>
> Thanks!
>
> Mark
>
>
>
>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
> _________________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.__org
> <mailto:OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <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
>
More information about the OpenStack-dev
mailing list