<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I was under the assumption that the ``reader`` role wouldn't be specific to the actions of either operators or regular end users. I thought the intention was to leverage the scope of the assignment to answer that question for us.<div><br></div><div>For example:</div><div><br></div><div>Let's assume Sarah is granted the reader role on the system (``openstack role add --user sarah --system all reader``). In theory, she has the ability to list system-specific resources, like endpoints, services, domains, or compute hosts. She can perform audits on the deployment infrastructure. If Chris has the reader role on a project (``openstack role add --user chris --project foobar reader``), he should theoretically have the ability to list instances and volumes within the project. Even though Chris has the reader role, he doesn't have the ability to list system-specific resources, because he doesn't have the system role assignment Sarah has.</div><div><br></div><div>We can expand the example to include domain support, too. If Jane has a reader role on a domain (``openstack role add --user jane --domain baz reader``), she theoretically has the ability to view things owned by that domain, like users, groups, or projects whose domain ID is ``baz``.</div><div><br></div><div>The same role is used in all three cases, but the target in each user's role assignment is important, too. This might be easier to see in practice between system [0], domain] [1], and project [2] readers all using the ``reader`` role. In my opinion, this gives us more bang for our buck as far as role definitions are concerned. We aren't worried about defining system-reader, domain-reader, and project-reader roles. Additionally, I cringe a little bit thinking about the custom policy required for those cases and the confusion operators might have when Jane gets the project-reader role assignment on a domain.</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/619329/3/keystone/tests/unit/protection/v3/test_endpoints.py@31">https://review.openstack.org/#/c/619329/3/keystone/tests/unit/protection/v3/test_endpoints.py@31</a></div><div>[1] <a href="https://review.openstack.org/#/c/619332/4/keystone/tests/unit/protection/v3/test_endpoints.py@131">https://review.openstack.org/#/c/619332/4/keystone/tests/unit/protection/v3/test_endpoints.py@131</a></div><div>[2] <a href="https://review.openstack.org/#/c/619281/5/keystone/tests/unit/protection/v3/test_endpoints.py,unified@376">https://review.openstack.org/#/c/619281/5/keystone/tests/unit/protection/v3/test_endpoints.py,unified@376</a></div><div><br></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018 at 8:27 AM Colleen Murphy <<a href="mailto:colleen@gazlene.net">colleen@gazlene.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Tagging keystone<br>
<br>
On Thu, Dec 13, 2018, at 3:18 PM, <a href="mailto:cristian.calin@orange.com" target="_blank">cristian.calin@orange.com</a> wrote:<br>
> As operators, we have a need for both cases and actually a 3rd one as <br>
> well which should be domain scoped.<br>
> I think the definition of reader should also include a scope (cloud-<br>
> wide, domain specific or project specific) so that we don’t need <br>
> different roles.<br>
> This might be a more fundamental change though as the scoping is static <br>
> today, I mean defined in the policy files/code.<br>
> <br>
> Cristian Calin<br>
> <br>
> From: Adam Young [mailto:<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>] <br>
> Sent: Thursday, December 13, 2018 3:09 AM<br>
> To: List, OpenStack<br>
> Subject: Meaning of role name: auditor versus reader<br>
> <br>
> We've recently come to accept reader as one of the default roles.  <br>
> However, one thing that is not clear to me is the intention:  is this <br>
> designed to be the readonly set of operations that an admin can do, or <br>
> the read only set of operations that a member can do?<br>
> <br>
> Should we really have two read-only roles, one for each case?  Perhaps <br>
> the admin-read-only should be called auditor, and then reader is for <br>
> member only operations?<br>
> <br>
> _________________________________________________________________________________________________________________________<br>
> <br>
> Ce message et ses pieces jointes peuvent contenir des informations <br>
> confidentielles ou privilegiees et ne doivent donc<br>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez <br>
> recu ce message par erreur, veuillez le signaler<br>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages <br>
> electroniques etant susceptibles d'alteration,<br>
> Orange decline toute responsabilite si ce message a ete altere, deforme <br>
> ou falsifie. Merci.<br>
> <br>
> This message and its attachments may contain confidential or privileged <br>
> information that may be protected by law;<br>
> they should not be distributed, used or copied without authorisation.<br>
> If you have received this email in error, please notify the sender and <br>
> delete this message and its attachments.<br>
> As emails may be altered, Orange is not liable for messages that have <br>
> been modified, changed or falsified.<br>
> Thank you.<br>
> <br>
<br>
</blockquote></div>