On Jun 5, 2015, at 19:25, Bhandaru, Malini K <[email protected]>
wrote:
Continuing with David?s example and the need to control access to a Swift
object that Adam points out,
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.
Alternately and encapsulating token
<Glance-token <user-token>> -- keeping it simple, only two levels. This
protects from on the cusp expired user-tokens.
Could check user quota before attempting the storage.
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.
Support was recently added to the Swift server. (Glance -> Swift support should
land in Liberty.)
In the near future we are looking to make all inter-service (e.g. Nova
->glance) communication have the service token.
This design was specifically implemented for the case you're describing.
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.
Should user not have paid dues, Glance knows which objects to garbage collect!
Regards
Malini
From: Adam Young [mailto:[email protected]]
Sent: Friday, June 05, 2015 4:11 PM
To: [email protected]
Subject: Re: [openstack-dev] [Glance][Keystone] Glance and trusts
On 06/05/2015 10:39 AM, Dolph Mathews wrote:
On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick <[email protected]> wrote:
I did suggest another solution to Adam whilst we were in Vancouver, and
this mirrors what happens in the real world today when I order something
from a supplier and a whole supply chain is involved in creating the end
product that I ordered. This is not too dissimilar to a user requesting
a new VM. Essentially each element in the supply chain trusts the two
adjacent elements. It has contracts with both its customers and its
suppliers to define the obligations of each party. When something is
ordered from it, it trusts the purchaser, and on the strength of this,
it will order from its suppliers. Each element may or may not know who
the original customer is, but if it needs to know, it trusts the
purchaser to tell it. Furthermore the customer does not need to delegate
any of his/her permissions to his/her supplier. If we used such a system
of trust between Openstack services, then we would not need delegation
of authority and "trusts" as they are implemented today. It could
significantly simplify the interactions between OpenStack services.
+1! I feel like this is the model that we started with in OpenStack, and have
grown additional complexity over time without much benefit.
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.
David's example elides the fact that there are checks built in to the supply
chain system to prevent cheating.
regards
David
On 03/06/2015 21:03, Adam Young wrote:
On 06/02/2015 12:57 PM, Mikhail Fedosin wrote:
Hello! I think it's a good time to discuss implementation of trusts in
Glance v2 and v3 api.
Currently we have two different situations during image creation where
our token may expire, which leads to unsuccessful operation.
First is connection between glance-api and glance-registry. In this
case we have a solution (https://review.openstack.org/#/c/29967/) -
use_user_token parameter in glance-api.conf, but it is True by default
. If it's changed to False then glance-api will use its own
credentials to authorize in glance-registry and it prevents many
possible issues with user token expiration. So, I'm interested if
there are some performance degradations if we change use_user_token to
False and what are the reasons against making it the default value.
Second one is linked with Swift. Current implementation uploads chunks
one by one and requires authorization each time. It may lead to
problems: for example we have to upload 100 chunks, after 99th one,
token expired and glance can't upload the last one, catches an
exception and tries to remove stale chunks from storage. Of course it
will fail, because token is not valid anymore, and that's why there
will be 99 garbage objects in the storage.
With Single-tenant mode glance uses its own credentials to upload
files, so it's possible to create new connection on each chunk upload
or catch Unauthorized exception and recreate connections only in that
cases. But with Multi-tenant mode there is no way to do it, because
user credentials are required. So it seems that trusts is the only one
solution here.
The problem with using trusts is that it would need to be created
per-user, and that is going to be expensive. It would be possible, as
Heat does something of this nature:
1. User calls glance,
2. Glance creates a trust with some limitation, either time or number of
uses
3. Trusts are used for all operations with swift.
4. Glance should clean up the trust when it is complete.
I don't love the solution, but I think it is the best we have. Ideally
the user would opt in to the trust, but in this case, it is kindof
implicit by them calling the API.
We should limit the trust creation to only have those roles (or a
subset) on the token used to create the trust.
I would be happy to hear your opinions on that matter. If you know
other situations where trusts are useful or some other approaches
please share.
Best regards,
Mike Fedosin
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openstack.org/pipermail/openstack-dev/attachments/20150606/20b20ca2/attachment-0001.html>
------------------------------
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
