Open Stack

I'm a bit late to the game here, and others have summed this up
excellently, but i'll add my 2c. I think option 2 is the way to go, user
and project IDs will absolutely work best as they are immutable.

On Fri, Jun 10, 2016 at 4:52 AM, Coles, Alistair <alistair.coles at hpe.com>
wrote:

> Thai,
>
>
>
> (repeating some of what we have discussed in private for others’ benefit)
>
>
>
> The Swift docs state “Be sure to use Keystone UUIDs rather than names in
> container ACLs” [1]. The guidance is re-iterated here [2] “…names must no
> longer be used in cross-tenant ACLs…”. They then go on to explain that for
> backwards compatibility (i.e. to not break ACLS that have already been
> persisted in Swift) names in ACLs are supported in the default domain only.
>
>
>
> The intent was not to encourage the continued use of names in the default
> domain (or while using keystone v2), nor to suggest that was “safe”, but to
> recognize that names had previously been used in contexts where names were
> unique and the ‘:’ separator was safe. In fact, Swift provides an option to
> disallow name matching in **all** contexts when no such backwards
> compatibility is required.
>
>
>
> At the time we made those changes (c. Atlanta summit) the input I had from
> Keystone devs was that names were not globally unique (with keystone v3),
> were mutable and should not be persisted. Hence the swift docs guidance. We
> actually considered preventing any new ACL being set with names, but to do
> so requires distinguishing a name string from a UUID string, which we
> didn’t find a solution for.
>
>
>
> So in response to your argument “If we are allowing V2 to store names [{
> project, name }], I do not see why we should not allow the same for V3 [{
> domain, project, name }]” : yes, we are allowing names in ACLs in some
> circumstances, but only for backwards compatibility, and we are not
> encouraging it. Having gone through the pain of dealing with names in
> existing persisted ACLs, I am reluctant to encourage their
> continued/renewed use.
>
>
>
> Are their examples of any other projects requiring names rather than UUIDs
> in ACLs, or for other purposes, that we can learn from?
>
>
>
> The idea discussed here [3] (not implemented) was that names could be
> supported in a JSON ACL format but should be resolved to UUIDs before
> persisting in Swift. That way a user’s name can change but since their
> request token is resolved to UUID then any persisted ACL would still match.
> As has already been mentioned in another reply on this thread, Swift has a
> JSON ACL format for “v1”/TempAuth account level ACLs [4] that could perhaps
> be implemented for keystoneauth and then extended to containers.
>
>
>
> Alistair
>
>
>
> [1]
> http://docs.openstack.org/developer/swift/overview_auth.html#access-control-using-keystoneauth
>
> [2] http://docs.openstack.org/developer/swift/middleware.html#keystoneauth
>
> [3] https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3
>
> [4] http://docs.openstack.org/developer/swift/overview_auth.html#tempauth
>
>
>
>
>
>
>
> *From:* Thai Q Tran [mailto:tqtran at us.ibm.com]
> *Sent:* 06 June 2016 21:06
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at lists.openstack.org>
> *Subject:* [openstack-dev] [swift][keystone] Using JSON as future ACL
> format
>
>
>
> Hello all,
>
> Hope everyone had a good weekend, and hope this email does not ruin your
> next.
> We had a small internal discussion at IBM and here are some of the
> findings that I will present to the wider community.
>
> 1. The ":" separator that swift currently uses is not entirely safe since
> LDAP can be configured to allow special characters in user IDs. It
> essentially means no special characters are safe to use as separators. I am
> not sure how practical this is, but its something to consider.
>
> 2. Since names are not guaranteed to be immutable, we should store
> everything via IDs. Currently, for backward compatibility reasons, Swift
> continues to support names for for V2. Keep in mind that V2 does not
> guarantee that names are immutable either. Given this fact and what we know
> from #1, we can say that names are mutable for both V2 and V3, and that any
> separators we use are fallible. In other words, using a separator for names
> or ids will not work 100% of the time.
>
> 3. Keystone recently enabled URL safe naming of project and domains for
> their hierarchal work. As a by product of that, if the option is enabled,
> Swift can essentially use the reserved characters as separators. The list
> of reserved characters are listed below. The only question remaining, how
> does Keystone inform Swift that this option is enabled? or Swift can add an
> separator option that is a subset of the characters below and leave it to
> the deployer to configure it.
>
> ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |"$" | ","
>
>
> https://github.com/openstack/keystone/commit/60b52c1248ddd5e682838d9e8ba853789940c284
> http://www.ietf.org/rfc/rfc2396.txt
>
> 3. As mentioned in the KeystoneAuthACL write up in Atlanta, JSON format is
> one of the option going forward. The article goes on to mention that we
> should store only user IDs (avoiding the mutable names issue). It outlined
> a process and reverse-process that would allow names to be use but
> mentioned an overhead cost to Keystone. I personally think is the right
> approach going forward since it negate the use of a separator altogether.
>
> Whether we chose to store the user IDs or names as metadata is another
> issue. But on a side note, I have tested this the changing names in V2 and
> it has the same exact problem as V3. If we are allowing V2 to store names
> [{ project, name }], I do not see why we should not allow the same for V3
> [{ domain, project, name }]. This would remove the overhead cost to
> Keystone. And of course, you still have the option to store things as IDs
> [{ domain, project, id }].
>
> https://wiki.openstack.org/wiki/Swift/ContainerACLWithKeystoneV3
>
> My intention is to spark discussion around this topic with the goal of
> moving the Swift community toward accepting the JSON format. Whether we
> store it as names or ids can be a discussion for another time. If you made
> it this far, thanks for reading! Your thoughts will be much appreciated.
>
> Thanks,
> Thai (tqtran)
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?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/20160630/fe4f2b90/attachment.html>