Open Stack

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.

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