<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Jun 5, 2015, at 19:25, Bhandaru, Malini K <<a href="mailto:malini.k.bhandaru@intel.com">malini.k.bhandaru@intel.com</a>> wrote:<br><br></div><blockquote type="cite"><div>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.hoenzb
        {mso-style-name:hoenzb;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->


<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Continuing with David’s example and the need to control access to a Swift object that Adam points out,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">How about using the Glance token from glance-API service to glance-registry but carry along extra data in the call, namely user-id, domain, and public/private
 information, so the object can be access controlled.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Alternately and encapsulating token<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><Glance-token <user-token>> -- keeping it simple, only two levels.  This protects from on the cusp expired user-tokens.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Could check user quota before attempting the storage.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"></span></p></div></div></blockquote><div><br></div><div>We already went over this type of design and determined it was sub-optimal. Instead we allow for passing the X-SERVICE-TOKEN, which is being passed in addition to the auth token. Right now I do not believe that X-SERVICE-TOKEN is being used anywhere. In the near future we are looking to make all inter-service (e.g. Nova ->glance) communication have the service token. </div><div><br></div><div>This design was specifically implemented for the case you're describing. </div><div><br></div><div>In theory it would be possible to allow the quota check / read with only a service token (and a proper policy.json) but would require the user's token to do writes. </div><div><br></div><br><blockquote type="cite"><div><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Should user not have paid dues, Glance knows which objects to garbage collect!<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Malini<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Adam Young [<a href="mailto:ayoung@redhat.com">mailto:ayoung@redhat.com</a>]
<br>
<b>Sent:</b> Friday, June 05, 2015 4:11 PM<br>
<b>To:</b> <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
<b>Subject:</b> Re: [openstack-dev] [Glance][Keystone] Glance and trusts<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 06/05/2015 10:39 AM, Dolph Mathews wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick <<a href="mailto:d.w.chadwick@kent.ac.uk" target="_blank">d.w.chadwick@kent.ac.uk</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">I did suggest another solution to Adam whilst we were in Vancouver, and<br>
this mirrors what happens in the real world today when I order something<br>
from a supplier and a whole supply chain is involved in creating the end<br>
product that I ordered. This is not too dissimilar to a user requesting<br>
a new VM. Essentially each element in the supply chain trusts the two<br>
adjacent elements. It has contracts with both its customers and its<br>
suppliers to define the obligations of each party. When something is<br>
ordered from it, it trusts the purchaser, and on the strength of this,<br>
it will order from its suppliers. Each element may or may not know who<br>
the original customer is, but if it needs to know, it trusts the<br>
purchaser to tell it. Furthermore the customer does not need to delegate<br>
any of his/her permissions to his/her supplier. If we used such a system<br>
of trust between Openstack services, then we would not need delegation<br>
of authority and "trusts" as they are implemented today. It could<br>
significantly simplify the interactions between OpenStack services.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">+1! I feel like this is the model that we started with in OpenStack, and have grown additional complexity over time without much benefit.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
We could roll Glance into Nova, too, and get the same benefit.  There is a reason we have separate services.  GLance shoud not Trust Nova for all operations, just some.<br>
<br>
David's example elides the fact that there  are checks built in to the supply chain system to prevent cheating.<br>
<br>
<br>
<br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
regards<br>
<span class="hoenzb"><span style="color:#888888">David</span></span><o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
On 03/06/2015 21:03, Adam Young wrote:<br>
> On 06/02/2015 12:57 PM, Mikhail Fedosin wrote:<br>
>> Hello! I think it's a good time to discuss implementation of trusts in<br>
>> Glance v2 and v3 api.<br>
>><br>
>> Currently we have two different situations during image creation where<br>
>> our token may expire, which leads to unsuccessful operation.<br>
>><br>
>> First is connection between glance-api and glance-registry. In this<br>
>> case we have a solution (<a href="https://review.openstack.org/#/c/29967/" target="_blank">https://review.openstack.org/#/c/29967/</a>) -<br>
>> use_user_token parameter in glance-api.conf, but it is True by default<br>
>> . If it's changed to False then glance-api will use its own<br>
>> credentials to authorize in glance-registry and it prevents many<br>
>> possible issues with user token expiration. So, I'm interested if<br>
>> there are some performance degradations if we change use_user_token to<br>
>> False and what are the reasons against making it the default value.<br>
>><br>
>> Second one is linked with Swift. Current implementation uploads chunks<br>
>> one by one and requires authorization each time. It may lead to<br>
>> problems: for example we have to upload 100 chunks, after 99th one,<br>
>> token expired and glance can't upload the last one, catches an<br>
>> exception and tries to remove stale chunks from storage. Of course it<br>
>> will fail, because token is not valid anymore, and that's why there<br>
>> will be 99 garbage objects in the storage.<br>
>> With Single-tenant mode glance uses its own credentials to upload<br>
>> files, so it's possible to create new connection on each chunk upload<br>
>> or catch Unauthorized exception and recreate connections only in that<br>
>> cases. But with Multi-tenant mode there is no way to do it, because<br>
>> user credentials are required. So it seems that trusts is the only one<br>
>> solution here.<br>
> The problem with using trusts is that it would need to be created<br>
> per-user, and that is going to be expensive.  It would be possible, as<br>
> Heat does something of this nature:<br>
><br>
> 1. User calls glance,<br>
> 2. Glance creates a trust with some limitation, either time or number of<br>
> uses<br>
> 3.  Trusts are used for all operations with swift.<br>
> 4. Glance should clean up the trust when it is complete.<br>
><br>
> I don't love the solution, but I think it is the best we have.  Ideally<br>
> the user would opt in to the trust, but in this case, it is kindof<br>
> implicit by them calling the API.<br>
><br>
><br>
> We should limit the trust creation to only have those roles (or a<br>
> subset) on the token used to create the trust.<br>
><br>
><br>
><br>
><br>
>> I would be happy to hear your opinions on that matter. If you know<br>
>> other situations where trusts are useful or some other approaches<br>
>> please share.<br>
>><br>
>> Best regards,<br>
>> Mike Fedosin<br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</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><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<pre>__________________________________________________________________________<o:p></o:p></pre>
<pre>OpenStack Development Mailing List (not for usage questions)<o:p></o:p></pre>
<pre>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><o:p></o:p></pre>
<pre><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></pre>
<p class="MsoNormal"><o:p> </o:p></p>
</div>


</div></blockquote><blockquote type="cite"><div><span>__________________________________________________________________________</span><br><span>OpenStack Development Mailing List (not for usage questions)</span><br><span>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe</span><br><span><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></span><br></div></blockquote></body></html>