Open Stack

On Tue, 2021-01-26 at 17:28 +0100, Gorka Eguileor wrote:
> On 26/01, Pete Zaitcev wrote:
> > On Tue, 26 Jan 2021 11:22:45 +0100
> > Gorka Eguileor <geguileo at redhat.com> wrote:
> > 
> > > On 19/01, Lance Bragstad wrote:
> > 
> > > > TL;DR - OpenStack services implementing secure RBAC should update default
> > > > policies with the `reader` role in a consistent manner, where it is not
> > > > meant to protect sensitive information.
> > 
> > > I have just one question regarding your TL;DR, shouldn't it be "where it
> > > is meant to protect sensitive information"?
> > > 
> > > As I understood it the reader should be updated so it doesn't expose
> > > sensitive information (thus protecting it) because it's the least
> > > privileged role.
> > 
> > I think Lance means that the reader role can see what member sees
> > (in any scope - system, domain, project). If a member sees some sensitive
> > information, then reader is not a place to make access reduction. In fact
> > it's harmful, because reader is not emulating member sufficiently for
> > being useful for anything. At least that's how I read Lance's intent.
> > 
> 
> Hi Pete,
> 
> What I understood was that the reader wouldn't be able to see any
> sensitive information, not even from a user.
> 
> Erno brought up a specific case with Glance and how a user may be able
> to see their licenses but a reader shouldn't.
> 
> So either I'm misunderstanding something or Erno's concerns won't be
> addressed with our current approach.
> 
> Cheers,
> Gorka.

i have not tought about what we want the sematics to be yet but we might want more then one reader role

e.g. "reader" which has readonly access to non sensitive info and "privledged_reader" which woudl be a read only
form of perhaps member with perhaps yet another "admin_reader for readonly project_admin.

my initall assumtion was the only detla between reader and member would be reader cannot modify things, i was not
expecting it to filter out sensitive info but i also was not expecting it to have access to admin only data.


a better approch for sensive info might be to require (reader and private) where we use private to denote anything a user with member can see but
reader should not be able to see by default.

if we did that i would define privledged_reader= (reader and private)
member would then imply privledged_reader instead of just reader

im not sure if that works in the larger context but i think filtering out lisince info via reader is not something that was orginally inteneded
so that need something like "private"  or "member_only" (privledged_reader= (reader and member_only)) to model that.


> 
> 
> > > > I think it's clear that there are APIs and resources in OpenStack that fall
> > > > into a special category where we shouldn't expose certain information to
> > > > the lowest level of the role hierarchy, regardless of the scope. But, the
> > > > role implication functionality served a purpose initially to deliver a
> > > > least-privileged role used only for read operations within a given scope. I
> > > > think breaking that implication now is confusing considering we implemented
> > > > the implication in Rocky [3], but I think future work for an elevated
> > > > read-only role is a good path forward.
> > 
> > That's not going to do a whole lot to simplify those check strings.
> > Perfect example of kicking the can down the road and committing to
> > more technical baggage.
> > 
> > -- Pete
> > 
> 
>