Swift keystoneauth middleware allows container ACLs to specify 'cross-tenant' access in the form tenant:user where tenant and user can be a UUID, a name or a wildcard *. With the introduction of domains with the keystone v3 API, names (of both tenants and users) are no longer globally unique and a re only unique within a domain. Consequently, cross-tenant ACLs specified using unqualified names will not unambiguous.
Discussion of forward looking options:
Allow only UUIDs (or wildcards) in ACLs when using keystone v3.
Require domain qualified names in ACLs. An obstacle to this is that keystone currently has no reserved characters in names, and therefore no character that could be used as a separator in a qualified name. This may change if keystone adopts and enforces a normative way to express domain-qualified names (or hierarchical names). E.g. if keystone were to reserve the '@@' string then this could be used as a separator between user/tenant names and domain names then swift could accept ACLs having the form tenant_name@@domain_name:user_name@@domain_name.
Provide a new JSON encoded structured ACL specification in which names and domains are explicitly called out.
Discussion of backwards compatibility issues
Existing systems have unqualified names in ACLs. How can we migrate to a keystone v3 environment with domains and preserve the functionality of those existing ACLs?
1. In some instances global name uniqueness will be enforced independently of keystone. In this case a config flag could be used to permit unqualified names to continue to be used in ACLs.
2. Re-write all existing ACLs to a new domain qualified format.
To be continued...