Secure RBAC work
lbragstad at gmail.com
Tue Jan 19 22:31:23 UTC 2021
On Tue, Jan 19, 2021 at 4:28 PM Lance Bragstad <lbragstad at gmail.com> wrote:
> 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 .
> 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 . 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.
Correction. The admin role implies the member role and the member role
implies the reader role.
> 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
> 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 .
> 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 , 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 . 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 . 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 .
>  https://review.opendev.org/q/topic:secure-rbac
>  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].*
>  https://review.opendev.org/c/openstack/keystone/+/771509
>  https://releases.openstack.org/wallaby/schedule.html
>  https://etherpad.opendev.org/p/default-policy-meeting-agenda
> On Thu, Dec 10, 2020 at 7:15 PM Ghanshyam Mann <gmann at ghanshyammann.com>
>> ---- 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 .
>> For context, we have been gradually improving policy enforcement for years.
>> We started by improving policy formats, registering default policies into
>> code , providing better documentation for policy writers, implementing
>> necessary identity concepts in keystone , developing support for those
>> concepts in libraries , and consuming all of those
>> changes to provide secure default policies in a way operators can consume
>> and roll out to their users .
>> > All of this work is in line with some high-level documentation we
>> started writing about three years ago .
>> > 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 .
>> > The work we currently have in progress  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.
>> > I hope this helps clarify or explain the patches being proposed.
>> > As always, I'm happy to elaborate on specific concerns if folks have
>> > Thanks,
>> > Lance
>> >  https://bugs.launchpad.net/keystone/+bug/968696/
>> > 
>> > 
>> >  https://review.opendev.org/c/openstack/keystoneauth/+/529665
>> > 
>> >  https://review.opendev.org/c/openstack/oslo.context/+/530509
>> >  https://review.opendev.org/c/openstack/keystonemiddleware/+/564072
>> >  https://review.opendev.org/c/openstack/oslo.policy/+/578995
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
>> > 
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss