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 <[email protected]> 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:[email protected]] > *Sent:* 06 June 2016 21:06 > *To:* OpenStack Development Mailing List (not for usage questions) < > [email protected]> > *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: [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
