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:tqt...@us.ibm.com]
Sent: 06 June 2016 21:06
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
