IN an attempt to keep the cloud sample file backwards compatible, the cloud_admin rule was modified like this:
"cloud_admin": "role:admin and (is_admin_project:True or domain_id:admin_domain_id)",
This is wrong: the cloud sample is managing admin based on an admin domain, and a domain scoped token will never have is_admin_project: True in it. However, the migration path has ALL tokens tagged this way, and this will violate the security of the file.
This is not a problem yet, as the "is_admin_project" flag is going to be enforced by oslo-context, and that has not yet been integrated into the policy check in keystone. If it were, this would be a security hole.
I think this bug can be made public, but starting with it as private until it is reviewed.
IN an attempt to keep the cloud sample file backwards compatible, the cloud_admin rule was modified like this:
"cloud_admin": "role:admin and (is_admin_ project: True or domain_ id:admin_ domain_ id)",
This is wrong: the cloud sample is managing admin based on an admin domain, and a domain scoped token will never have is_admin_project: True in it. However, the migration path has ALL tokens tagged this way, and this will violate the security of the file.
This is not a problem yet, as the "is_admin_project" flag is going to be enforced by oslo-context, and that has not yet been integrated into the policy check in keystone. If it were, this would be a security hole.
I think this bug can be made public, but starting with it as private until it is reviewed.