On Tue, 26 Jan 2021 11:22:45 +0100 Gorka Eguileor <geguileo@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