Open Stack

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.

For example:

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.

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``.

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.

[0]
https://review.openstack.org/#/c/619329/3/keystone/tests/unit/protection/v3/test_endpoints.py@31
[1]
https://review.openstack.org/#/c/619332/4/keystone/tests/unit/protection/v3/test_endpoints.py@131
[2]
https://review.openstack.org/#/c/619281/5/keystone/tests/unit/protection/v3/test_endpoints.py,unified@376


On Thu, Dec 13, 2018 at 8:27 AM Colleen Murphy <colleen at gazlene.net> wrote:

> Tagging keystone
>
> On Thu, Dec 13, 2018, at 3:18 PM, cristian.calin at orange.com wrote:
> > As operators, we have a need for both cases and actually a 3rd one as
> > well which should be domain scoped.
> > I think the definition of reader should also include a scope (cloud-
> > wide, domain specific or project specific) so that we don’t need
> > different roles.
> > This might be a more fundamental change though as the scoping is static
> > today, I mean defined in the policy files/code.
> >
> > Cristian Calin
> >
> > From: Adam Young [mailto:ayoung at redhat.com]
> > Sent: Thursday, December 13, 2018 3:09 AM
> > To: List, OpenStack
> > Subject: Meaning of role name: auditor versus reader
> >
> > We've recently come to accept reader as one of the default roles.
> > However, one thing that is not clear to me is the intention:  is this
> > designed to be the readonly set of operations that an admin can do, or
> > the read only set of operations that a member can do?
> >
> > Should we really have two read-only roles, one for each case?  Perhaps
> > the admin-read-only should be called auditor, and then reader is for
> > member only operations?
> >
> >
> _________________________________________________________________________________________________________________________
> >
> > Ce message et ses pieces jointes peuvent contenir des informations
> > confidentielles ou privilegiees et ne doivent donc
> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> > recu ce message par erreur, veuillez le signaler
> > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> > electroniques etant susceptibles d'alteration,
> > Orange decline toute responsabilite si ce message a ete altere, deforme
> > ou falsifie. Merci.
> >
> > This message and its attachments may contain confidential or privileged
> > information that may be protected by law;
> > they should not be distributed, used or copied without authorisation.
> > If you have received this email in error, please notify the sender and
> > delete this message and its attachments.
> > As emails may be altered, Orange is not liable for messages that have
> > been modified, changed or falsified.
> > Thank you.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181213/da0eb691/attachment.html>