Hey all,
I want to follow up on this thread because there's been some discussion and questions (some of which are in reviews) as services work through the proposed changes [0].
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.
In the process of reviewing changes for various resources, some folks raised concerns about the `reader` role definition.
One of the intended use-cases for implementing a `reader` role was to use it for auditing, as noted in the keystone definitions for each role and persona [1]. Another key point of that document, and the underlying design of secure RBAC, is that the default roles have role implications built between them (e.g., reader implies member, and member implies admin). This detail serves two important functions.
First, it reduces duplication in check strings because keystone expands role implications in token response bodies. For example, someone with the `admin` role on a project will have `member` and `reader` roles in their token body when they authenticate for a token or validate a token. This reduces the complexity of our check strings by writing the policy to the highest level of authorization required to access an API or resource. Users with anything above that level will work through the role implications feature.
Second, it reduces the need for extra role assignments. If you grant someone the `admin` role on a project you don't need to also give them `reader` and `member` role assignments. This is true regardless of how services implement check strings.
Ultimately, the hierarchical role structure in keystone and role expansion in token responses give us shorter check strings and less role assignments. But, one thing we're aware of now is that we need to be careful how we expose certain information to users via the `reader` role, since it is the least-privileged role in the hierarchy. For example, one concern was exposing license key information in images to anyone with the `reader` role on the system. Some deployments, depending on their security posture or auditing targets, might not allow sensitive information to be implicitly exposed. Instead, they may require deployments to explicitly grant access to sensitive information [2].
So what do we do moving forward?
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. Eventually, keystone can consider implementing support for a new default role, which implies `reader`, making all the work we do today still useful. At that time, we can update relevant policies to expose sensitive information with the elevated read-only role. I suspect this will be a much smaller set of APIs and policies. I think this approach strikes a balance between what we have today, and a way to move forward that still protects sensitive data.
I proposed an update to the documentation in keystone to clarify this point [4]. It also doesn't assume all audits are the same. Instead, it phrases the ability to use `reader` roles for auditing in a way that leaves that up to the deployer and auditor. I think that's an important detail since different deployments have different security requirements. Instead of assuming everyone can use `reader` for auditing, we can give them a list of APIs they can interact with as a `reader` (or have them generate those policies themselves, especially if they have custom policy) and let them determine if that access is sufficient for their audit. If it isn't, deployers aren't in a worse position today, but it emphasizes the importance of expanding the default roles to include another tier for elevated read-only permissions. Given where we are in the release cycle for Wallaby, I don't expect keystone to implement a new default role this late in the release [5]. Perhaps Xena is a better target, but I'll talk with Kristi about it next week during the keystone meeting.
I hope this helps clarify some of the confusion around the secure RBAC patches. If you have additional comments or questions about this topic, let me know. We can obviously iterate here, or use the policy pop up time slot which is in a couple of days [6].
Thanks,
Lance
[2] FedRAMP control AC -06 (01) is an example of this - The organization explicitly authorizes access to [Assignment:
organization-defined security functions (deployed in hardware, software,
and firmware) and security-relevant information].