Open Stack

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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160610/85c020b8/attachment.html>