I left a comment for you on the blueprint. I would love to see a more explicit definition on the tokens we're proposing do we have a blueprint for that? <br><br><div class="gmail_quote">On Tue, Dec 11, 2012 at 11:52 AM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
<div>On 12/11/2012 01:53 PM, Matt Joyce
wrote:<br>
</div>
<blockquote type="cite">I think there is a question as to the nature of what
is a fully qualified cloud instance.<br>
<br>
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.<br>
<br>
With cloud there is a fundamentally different environment that
promotes new needs.<br>
<br>
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. <br>
<br>
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.<br>
</blockquote></div>
Tickets are going to be signed by Keystone. The user needs to be
able to authenticate to Keystone to get the ticket. We can limit
access to keystone. But the requests come through via HTTP and we
don't have SPNEGO/GSSAPI. If we want to limit access to a host, it
would have to be based on the ipaddress of the requestor, which is
in the HTTP payload. I think that would need the full ABAC
implementation to enforce.<div class="im"><br>
<br>
<blockquote type="cite">
<br>
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? <br>
</blockquote></div>
THe delegation Blueprint starts to address this. I would appreciate
getting a review of it, and hearing your feedback:<br>
<br>
<a href="http://wiki.openstack.org/keystone/Delegation" target="_blank">http://wiki.openstack.org/keystone/Delegation</a><div><div class="h5"><br>
<br>
<blockquote type="cite">
<br>
<br>
<br>
-Matt<br>
<br>
<div class="gmail_quote">On Tue, Dec 11, 2012 at 7:01 AM, Adam
Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On 12/11/2012 08:06 AM, David Chadwick wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Mark<br>
<br>
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?<br>
</blockquote>
<br>
</div>
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"
<div>
<div><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
regards<br>
<br>
David<br>
<br>
<br>
On 10/12/2012 21:12, Mark Washenberger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I must be missing something. Thanks in advance for
correcting me!<br>
</blockquote>
<br>
Why would the user not have the role?<br>
</blockquote>
<br>
The idea behind this feature is that the user is not
authorized to<br>
upload an image, but Nova is authorized to upload an
image on the<br>
user's behalf. This feature would not be turned on by
default, but it<br>
should be available at a deployer's discretion.<br>
<br>
On Mon, Dec 10, 2012 at 12:14 PM, Adam Young <<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/10/2012 02:41 PM, Mark Washenberger wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So, in the case of this feature, the trustor (end
user) is going to<br>
delegate to the trustee (Glance) a role that the
trustor himself does<br>
not have? (Namely, some role that allows image
uploads.) That seems to<br>
violate the spirit of the the spec.<br>
</blockquote>
<br>
Nope. The user needs to have the role in the first
place.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I must be missing something. Thanks in advance for
correcting me!<br>
</blockquote>
<br>
Why would the user not have the role?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
markwash<br>
<br>
On Mon, Dec 10, 2012 at 10:56 AM, Yee, Guang <<a href="mailto:guang.yee@hp.com" target="_blank">guang.yee@hp.com</a>>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think the current trust BP should cover your
use case.<br>
<br>
<a href="http://wiki.openstack.org/Keystone/Trusts" target="_blank">http://wiki.openstack.org/Keystone/Trusts</a><br>
<br>
In your case, the trustee would be Image Service
or endpoint.<br>
<br>
<br>
Guang<br>
<br>
<br>
-----Original Message-----<br>
From: Mark Washenberger [mailto:<a href="mailto:mark.washenberger@markwash.net" target="_blank">mark.washenberger@markwash.net</a>]<br>
Sent: Monday, December 10, 2012 10:36 AM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] [Keystone] Trusts
and Explicit Impersonation<br>
<br>
David, Adam, (other Trusts/Auth folks. . .),<br>
<br>
Any thoughts on this?<br>
<br>
Thanks!<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
From: Mark Washenberger [mailto:<a href="mailto:mark.washenberger@markwash.net" target="_blank">mark.washenberger@markwash.net</a>]<br>
Sent: Friday, December 07, 2012 8:53 PM<br>
To: OpenStack Development Mailing List<br>
Subject: [openstack-dev] Trusts and Explicit
Impersonation<br>
<br>
<br>
<br>
Hi auth guys!<br>
<br>
<br>
<br>
As we continue to make progress towards
large service providers<br>
exposing<br>
their Glance deployments as public services,
one critical feature we<br>
need<br>
</blockquote>
</blockquote>
<br>
to<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
support is the ability to limit certain
actions (mostly image uploads,<br>
</blockquote>
</blockquote>
<br>
also<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
possibly image downloads) to use by Nova or
other trusted services, and<br>
restrict users from taking those actions
directly. Of course, this<br>
</blockquote>
</blockquote>
<br>
feature<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
would only be turned on by configuration,
and not likely by default.<br>
<br>
<br>
<br>
I had figured we could do this using some
features piggy-backed on<br>
keystone pki, and documented the use case in
this blueprint:<br>
<br>
</blockquote>
</blockquote>
<br>
<a href="https://blueprints.launchpad.net/keystone/+spec/keystone-explicit-impersonat" target="_blank">https://blueprints.launchpad.net/keystone/+spec/keystone-explicit-impersonat</a>
<br>
ion<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
I've been following the discussion of
Keystone Trusts with interest,<br>
and<br>
some questions have presented themselves. Is
there some way we could<br>
manipulate the Trust mechanism to provide
the auth feature Glance<br>
needs?<br>
Another (scarier for me) question: does the
Trusts proposal conflict<br>
with<br>
</blockquote>
</blockquote>
<br>
my<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
feature request?<br>
<br>
<br>
<br>
Thanks!<br>
<br>
Mark<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</blockquote>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br>