Open Stack

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

[0] https://review.opendev.org/q/topic:secure-rbac
[1]
https://docs.openstack.org/keystone/latest/admin/service-api-protection.html
[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].*
[3] https://docs.openstack.org/releasenotes/keystone/rocky.html#new-features
[4] https://review.opendev.org/c/openstack/keystone/+/771509
[5] https://releases.openstack.org/wallaby/schedule.html
[6] https://etherpad.opendev.org/p/default-policy-meeting-agenda

On Thu, Dec 10, 2020 at 7:15 PM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

>  ---- On Wed, 09 Dec 2020 14:04:57 -0600 Lance Bragstad <
> lbragstad at gmail.com> wrote ----
>  > Hey everyone,
>  >
>  > I wanted to take an opportunity to clarify some work we have been doing
> upstream, specifically modifying the default policies across projects.
>  >
>  > 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].
>  >
>  > All of this work is in line with some high-level documentation we
> started writing about three years ago [11][12][13].
>  >
>  > 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].
>  >
>  > 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.
>
> Thanks, Lance for pushing this work forwards. I completely agree and that
> is what we get feedback in
> forum sessions also that we should implement this in all the services
> first before we ask operators to
> move their cloud to the new RBAC.
>
> We discussed these in today's policy-popup meeting also and encourage
> every project to help in those
> patches to add tests and review. This will help to finish the work on
> priority and we can provide better
> RBAC experience to the deployer.
>
> -gmann
>
>  >
>  >
>  > I hope this helps clarify or explain the patches being proposed.
>  >
>  >
>  > As always, I'm happy to elaborate on specific concerns if folks have
> them.
>  >
>  >
>  > Thanks,
>  >
>  >
>  > Lance
>  >
>  >
>  > [0] https://bugs.launchpad.net/keystone/+bug/968696/
>  > [1]
> https://governance.openstack.org/tc/goals/selected/queens/policy-in-code.html
>  > [2]
> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html
>  > [3] https://review.opendev.org/c/openstack/keystoneauth/+/529665
>  > [4]
> https://review.opendev.org/c/openstack/python-keystoneclient/+/524415
>  > [5] https://review.opendev.org/c/openstack/oslo.context/+/530509
>  > [6] https://review.opendev.org/c/openstack/keystonemiddleware/+/564072
>  > [7] https://review.opendev.org/c/openstack/oslo.policy/+/578995
>  > [8]
> https://review.opendev.org/q/topic:%22system-scope%22+(status:open%20OR%20status:merged)
>  > [9]
> https://review.opendev.org/q/status:merged+topic:bp/policy-defaults-refresh+branch:master
>  > [10]
> https://review.opendev.org/q/topic:%22implement-default-roles%22+(status:open%20OR%20status:merged)
>  > [11]
> https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/policy-goals-and-roadmap.html
>  > [12]
> https://docs.openstack.org/keystone/latest/admin/service-api-protection.html
>  > [13]
> https://docs.openstack.org/keystone/latest/contributor/services.html#authorization-scopes
>  > [14]
> https://governance.openstack.org/tc/reference/popup-teams.html#secure-default-policies
>  > [15]
> https://review.opendev.org/q/topic:%2522secure-rbac%2522+status:open
>  >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210119/2049e1dc/attachment-0001.html>