<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 26, 2021 at 4:23 AM Gorka Eguileor <<a href="mailto:geguileo@redhat.com">geguileo@redhat.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 19/01, Lance Bragstad wrote:<br>
> Hey all,<br>
><br>
> I want to follow up on this thread because there's been some discussion and<br>
> questions (some of which are in reviews) as services work through the<br>
> proposed changes [0].<br>
><br>
> TL;DR - OpenStack services implementing secure RBAC should update default<br>
> policies with the `reader` role in a consistent manner, where it is not<br>
> meant to protect sensitive information.<br>
><br>
<br>
Hi Lance,<br>
<br>
Thank you very much for this great summary of all the different<br>
discussions and decisions.<br>
<br>
I have just one question regarding your TL;DR, shouldn't it be "where it<br>
is meant to protect sensitive information"?<br>
<br>
As I understood it the reader should be updated so it doesn't expose<br>
sensitive information (thus protecting it) because it's the least<br>
privileged role.<br>
<br>
Cheers,<br>
Gorka.<br></blockquote><div><br></div><div>I think you're understanding things correctly, and re-reading my original TL;DR I can see how the wording is confusing. Does the following help?<br></div><div><br></div><div><i>OpenStack services implementing secure RBAC should update default policies with the `reader` role in a consistent manner, where users with the `reader` role are not allowed to view sensitive information.<br></i></div><div><br></div><div>Nice catch, Gorka.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> In the process of reviewing changes for various resources, some folks<br>
> raised concerns about the `reader` role definition.<br>
><br>
> One of the intended use-cases for implementing a `reader` role was to use<br>
> it for auditing, as noted in the keystone definitions for each role and<br>
> persona [1]. Another key point of that document, and the underlying design<br>
> of secure RBAC, is that the default roles have role implications built<br>
> between them (e.g., reader implies member, and member implies admin). This<br>
> detail serves two important functions.<br>
><br>
> First, it reduces duplication in check strings because keystone expands<br>
> role implications in token response bodies. For example, someone with the<br>
> `admin` role on a project will have `member` and `reader` roles in their<br>
> token body when they authenticate for a token or validate a token. This<br>
> reduces the complexity of our check strings by writing the policy to the<br>
> highest level of authorization required to access an API or resource. Users<br>
> with anything above that level will work through the role implications<br>
> feature.<br>
><br>
> Second, it reduces the need for extra role assignments. If you grant<br>
> someone the `admin` role on a project you don't need to also give them<br>
> `reader` and `member` role assignments. This is true regardless of how<br>
> services implement check strings.<br>
><br>
> Ultimately, the hierarchical role structure in keystone and role expansion<br>
> in token responses give us shorter check strings and less role assignments.<br>
> But, one thing we're aware of now is that we need to be careful how we<br>
> expose certain information to users via the `reader` role, since it is the<br>
> least-privileged role in the hierarchy. For example, one concern was<br>
> exposing license key information in images to anyone with the `reader` role<br>
> on the system. Some deployments, depending on their security posture or<br>
> auditing targets, might not allow sensitive information to be implicitly<br>
> exposed. Instead, they may require deployments to explicitly grant access<br>
> to sensitive information [2].<br>
><br>
> So what do we do moving forward?<br>
><br>
> I think it's clear that there are APIs and resources in OpenStack that fall<br>
> into a special category where we shouldn't expose certain information to<br>
> the lowest level of the role hierarchy, regardless of the scope. But, the<br>
> role implication functionality served a purpose initially to deliver a<br>
> least-privileged role used only for read operations within a given scope. I<br>
> think breaking that implication now is confusing considering we implemented<br>
> the implication in Rocky [3], but I think future work for an elevated<br>
> read-only role is a good path forward. Eventually, keystone can consider<br>
> implementing support for a new default role, which implies `reader`, making<br>
> all the work we do today still useful. At that time, we can update relevant<br>
> policies to expose sensitive information with the elevated read-only role.<br>
> I suspect this will be a much smaller set of APIs and policies. I think<br>
> this approach strikes a balance between what we have today, and a way to<br>
> move forward that still protects sensitive data.<br>
><br>
> I proposed an update to the documentation in keystone to clarify this point<br>
> [4]. It also doesn't assume all audits are the same. Instead, it phrases<br>
> the ability to use `reader` roles for auditing in a way that leaves that up<br>
> to the deployer and auditor. I think that's an important detail since<br>
> different deployments have different security requirements. Instead of<br>
> assuming everyone can use `reader` for auditing, we can give them a list of<br>
> APIs they can interact with as a `reader` (or have them generate those<br>
> policies themselves, especially if they have custom policy) and let them<br>
> determine if that access is sufficient for their audit. If it isn't,<br>
> deployers aren't in a worse position today, but it emphasizes the<br>
> importance of expanding the default roles to include another tier for<br>
> elevated read-only permissions. Given where we are in the release cycle for<br>
> Wallaby, I don't expect keystone to implement a new default role this late<br>
> in the release [5]. Perhaps Xena is a better target, but I'll talk with<br>
> Kristi about it next week during the keystone meeting.<br>
><br>
> I hope this helps clarify some of the confusion around the secure RBAC<br>
> patches. If you have additional comments or questions about this topic, let<br>
> me know. We can obviously iterate here, or use the policy pop up time slot<br>
> which is in a couple of days [6].<br>
><br>
> Thanks,<br>
><br>
> Lance<br>
><br>
> [0] <a href="https://review.opendev.org/q/topic:secure-rbac" rel="noreferrer" target="_blank">https://review.opendev.org/q/topic:secure-rbac</a><br>
> [1]<br>
> <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>
> [2] FedRAMP control AC -06 (01) is an example of this - *The organization<br>
> explicitly authorizes access to [Assignment: organization-defined security<br>
> functions (deployed in hardware, software, and firmware) and<br>
> security-relevant information].*<br>
> [3] <a href="https://docs.openstack.org/releasenotes/keystone/rocky.html#new-features" rel="noreferrer" target="_blank">https://docs.openstack.org/releasenotes/keystone/rocky.html#new-features</a><br>
> [4] <a href="https://review.opendev.org/c/openstack/keystone/+/771509" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/keystone/+/771509</a><br>
> [5] <a href="https://releases.openstack.org/wallaby/schedule.html" rel="noreferrer" target="_blank">https://releases.openstack.org/wallaby/schedule.html</a><br>
> [6] <a href="https://etherpad.opendev.org/p/default-policy-meeting-agenda" rel="noreferrer" target="_blank">https://etherpad.opendev.org/p/default-policy-meeting-agenda</a><br>
><br>
> On Thu, Dec 10, 2020 at 7:15 PM Ghanshyam Mann <<a href="mailto:gmann@ghanshyammann.com" target="_blank">gmann@ghanshyammann.com</a>><br>
> wrote:<br>
><br>
> >  ---- On Wed, 09 Dec 2020 14:04:57 -0600 Lance Bragstad <<br>
> > <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<br>
> > upstream, specifically modifying the default policies across projects.<br>
> >  ><br>
> >  > These changes are the next phase of an initiative that’s been underway<br>
> > since Queens to fix some long-standing security concerns in OpenStack [0].<br>
> > For context, we have been gradually improving policy enforcement for years.<br>
> > We started by improving policy formats, registering default policies into<br>
> > code [1], providing better documentation for policy writers, implementing<br>
> > necessary identity concepts in keystone [2], developing support for those<br>
> > concepts in libraries [3][4][5][6][7][8], and consuming all of those<br>
> > changes to provide secure default policies in a way operators can consume<br>
> > and roll out to their users [9][10].<br>
> >  ><br>
> >  > All of this work is in line with some high-level documentation we<br>
> > started writing about three years ago [11][12][13].<br>
> >  ><br>
> >  > There are a handful of services that have implemented the goals that<br>
> > define secure RBAC by default, but a community-wide goal is still<br>
> > out-of-reach. To help with that, the community formed a pop-up team with a<br>
> > focused objective and disbanding criteria [14].<br>
> >  ><br>
> >  > The work we currently have in progress [15] is an attempt to start<br>
> > applying what we have learned from existing implementations to other<br>
> > projects. The hope is that we can complete the work for even more projects<br>
> > in Wallaby. Most deployers looking for this functionality won't be able to<br>
> > 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<br>
> > is what we get feedback in<br>
> > forum sessions also that we should implement this in all the services<br>
> > 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<br>
> > every project to help in those<br>
> > patches to add tests and review. This will help to finish the work on<br>
> > 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<br>
> > 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]<br>
> > <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]<br>
> > <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]<br>
> > <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]<br>
> > <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]<br>
> > <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]<br>
> > <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]<br>
> > <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]<br>
> > <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]<br>
> > <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]<br>
> > <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]<br>
> > <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>
> ><br>
<br>
</blockquote></div></div>