<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 19, 2021 at 4:28 PM Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hey all,</div><div><br></div><div>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].</div><div><br></div><div>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.</div><div><br></div><div>In the process of reviewing changes for various resources, some folks raised concerns about the `reader` role definition.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>Correction. The admin role implies the member role and the member role implies the reader role.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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].</div><div><br></div><div>So what do we do moving forward?</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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].<br></div><div><br></div><div>Thanks,</div><div><br></div><div>Lance</div><div><br></div><div>[0] <a href="https://review.opendev.org/q/topic:secure-rbac" target="_blank">https://review.opendev.org/q/topic:secure-rbac</a></div><div>[1] <a href="https://docs.openstack.org/keystone/latest/admin/service-api-protection.html" target="_blank">https://docs.openstack.org/keystone/latest/admin/service-api-protection.html</a></div><div>[2] FedRAMP control AC -06 (01) is an example of this - <i><span>The organization explicitly authorizes access to [Assignment:
organization-defined security functions (deployed in hardware, software,
and firmware) and security-relevant information].</span></i></div><div><span>[3] <a href="https://docs.openstack.org/releasenotes/keystone/rocky.html#new-features" target="_blank">https://docs.openstack.org/releasenotes/keystone/rocky.html#new-features</a></span></div><div><span>[4] <a href="https://review.opendev.org/c/openstack/keystone/+/771509" target="_blank">https://review.opendev.org/c/openstack/keystone/+/771509</a></span></div><div><span>[5] <a href="https://releases.openstack.org/wallaby/schedule.html" target="_blank">https://releases.openstack.org/wallaby/schedule.html</a></span></div><div><span>[6] <a href="https://etherpad.opendev.org/p/default-policy-meeting-agenda" target="_blank">https://etherpad.opendev.org/p/default-policy-meeting-agenda</a></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 10, 2020 at 7:15 PM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com" target="_blank">gmann@ghanshyammann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> ---- On Wed, 09 Dec 2020 14:04:57 -0600 Lance Bragstad <<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>> wrote ----<br>
> Hey everyone,<br>
> <br>
> I wanted to take an opportunity to clarify some work we have been doing upstream, specifically modifying the default policies across projects.<br>
> <br>
> These changes are the next phase of an initiative that’s been underway since Queens to fix some long-standing security concerns in OpenStack [0]. For context, we have been gradually improving policy enforcement for years. We started by improving policy formats, registering default policies into code [1], providing better documentation for policy writers, implementing necessary identity concepts in keystone [2], developing support for those concepts in libraries [3][4][5][6][7][8], and consuming all of those changes to provide secure default policies in a way operators can consume and roll out to their users [9][10].<br>
> <br>
> All of this work is in line with some high-level documentation we started writing about three years ago [11][12][13].<br>
> <br>
> There are a handful of services that have implemented the goals that define secure RBAC by default, but a community-wide goal is still out-of-reach. To help with that, the community formed a pop-up team with a focused objective and disbanding criteria [14].<br>
> <br>
> The work we currently have in progress [15] is an attempt to start applying what we have learned from existing implementations to other projects. The hope is that we can complete the work for even more projects in Wallaby. Most deployers looking for this functionality won't be able to use it effectively until all services in their deployment support it.<br>
<br>
Thanks, Lance for pushing this work forwards. I completely agree and that is what we get feedback in<br>
forum sessions also that we should implement this in all the services first before we ask operators to<br>
move their cloud to the new RBAC.<br>
<br>
We discussed these in today's policy-popup meeting also and encourage every project to help in those<br>
patches to add tests and review. This will help to finish the work on priority and we can provide better<br>
RBAC experience to the deployer. <br>
<br>
-gmann<br>
<br>
> <br>
> <br>
> I hope this helps clarify or explain the patches being proposed.<br>
> <br>
> <br>
> As always, I'm happy to elaborate on specific concerns if folks have them.<br>
> <br>
> <br>
> Thanks,<br>
> <br>
> <br>
> Lance<br>
> <br>
> <br>
> [0] <a href="https://bugs.launchpad.net/keystone/+bug/968696/" rel="noreferrer" target="_blank">https://bugs.launchpad.net/keystone/+bug/968696/</a><br>
> [1] <a href="https://governance.openstack.org/tc/goals/selected/queens/policy-in-code.html" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/goals/selected/queens/policy-in-code.html</a><br>
> [2] <a href="https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html</a><br>
> [3] <a href="https://review.opendev.org/c/openstack/keystoneauth/+/529665" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/keystoneauth/+/529665</a><br>
> [4] <a href="https://review.opendev.org/c/openstack/python-keystoneclient/+/524415" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/python-keystoneclient/+/524415</a><br>
> [5] <a href="https://review.opendev.org/c/openstack/oslo.context/+/530509" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/oslo.context/+/530509</a><br>
> [6] <a href="https://review.opendev.org/c/openstack/keystonemiddleware/+/564072" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/keystonemiddleware/+/564072</a><br>
> [7] <a href="https://review.opendev.org/c/openstack/oslo.policy/+/578995" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/oslo.policy/+/578995</a><br>
> [8] <a href="https://review.opendev.org/q/topic:%22system-scope%22+(status:open%20OR%20status:merged)" rel="noreferrer" target="_blank">https://review.opendev.org/q/topic:%22system-scope%22+(status:open%20OR%20status:merged)</a><br>
> [9] <a href="https://review.opendev.org/q/status:merged+topic:bp/policy-defaults-refresh+branch:master" rel="noreferrer" target="_blank">https://review.opendev.org/q/status:merged+topic:bp/policy-defaults-refresh+branch:master</a><br>
> [10] <a href="https://review.opendev.org/q/topic:%22implement-default-roles%22+(status:open%20OR%20status:merged)" rel="noreferrer" target="_blank">https://review.opendev.org/q/topic:%22implement-default-roles%22+(status:open%20OR%20status:merged)</a><br>
> [11] <a href="https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-goals-and-roadmap.html" rel="noreferrer" target="_blank">https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-goals-and-roadmap.html</a><br>
> [12] <a href="https://docs.openstack.org/keystone/latest/admin/service-api-protection.html" rel="noreferrer" target="_blank">https://docs.openstack.org/keystone/latest/admin/service-api-protection.html</a><br>
> [13] <a href="https://docs.openstack.org/keystone/latest/contributor/services.html#authorization-scopes" rel="noreferrer" target="_blank">https://docs.openstack.org/keystone/latest/contributor/services.html#authorization-scopes</a><br>
> [14] <a href="https://governance.openstack.org/tc/reference/popup-teams.html#secure-default-policies" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/reference/popup-teams.html#secure-default-policies</a><br>
> [15] <a href="https://review.opendev.org/q/topic:%2522secure-rbac%2522+status:open" rel="noreferrer" target="_blank">https://review.opendev.org/q/topic:%2522secure-rbac%2522+status:open</a><br>
> <br>
</blockquote></div>
</blockquote></div></div>