Open Stack

On Wed, 19 Jan 2022 at 16:12, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>
>  ---- On Wed, 19 Jan 2022 04:35:53 -0600 Mark Goddard <mark at stackhpc.com> wrote ----
>  > Hi,
>  >
>  > If you haven't been paying close attention, it would be easy to miss
>  > some of the upcoming RBAC changes which will have an impact on
>  > deployment projects. I thought I'd start a thread so that we can share
>  > how we are approaching this, get answers to open questions, and
>  > ideally all end up with a fairly consistent approach.
>  >
>  > The secure RBAC work has a long history, and continues to evolve.
>  > According to [1], we should start to see some fairly substantial
>  > changes over the next few releases. That spec is fairly long, but
>  > worth a read.
>  >
>  > In the yoga timeline [2], there is one change in particular that has
>  > an impact on deployment projects, "3. Keystone enforces scope by
>  > default". After this change, all of the deprecated policies that many
>  > still rely on in Keystone will be removed.
>  >
>  > In kolla-ansible, we have an etherpad [5] with some notes, questions
>  > and half-baked plans. We made some changes in Xena [3] to use system
>  > scope in some places when interacting with system APIs in Ansible
>  > tasks.
>  >
>  > The next change we have staged is to add the service role to all
>  > service users [4], in preparation for [2].
>  >
>  > Question: should the role be added with system scope or in the
>  > existing service project? The obvious main use for this is token
>  > validation, which seems to allow system or project scope.
>  >
>  > We anticipate that some service users may still require some
>  > project-scoped roles, e.g. when creating resources for octavia. We'll
>  > deal with those on a case by case basis.
>
> Service roles are planned for phase2 which is Z release[1]. The Idea here is
> service to service communication will happen with 'service' role (which keystone
> need to implement yet) and end users will keep using the what ever role
> is default (or overridden in policy file) which can be project or system scoped
> depends on the APIs.
>
> So at the end service-service APIs policy default will looks like
>
>  '(role:admin and system:network and project_id:%(project_id)s) or (role:service and project_name:service)'
>
> Say nova will use that service role to communicate to cinder and cinder policy will pass
> as service role is in OR in default policy.
>
> But let's see how they are going to be and if any challenges when we will implement
> it in Z cycle.

I'm not 100% on our reasoning for using the service role in yoga (I
wasn't in the discussion when we made the switch, although John
Garbutt was), although I can provide at least one reason.

Currently, we have a bunch of service users doing things like keystone
token validation using the admin role in the service project. If we
enforce scopes & new defaults in keystone, this will no longer work,
due to the default policy:

identity:validate_token: (role:reader and system_scope:all) or
rule:service_role or rule:token_subject

Now we could go and assign system-reader to all these users, but if
the end goal is to give them all the service role, and that allows
token validation, then to me that seems like a better path.

Currently, we're creating the service role during deploy & upgrade,
then assigning it to users. Keystone is supposed to create the service
role in yoga, so we can eventually drop that part.

Does this seem reasonable? Is keystone still on track to create the
service role in yoga?

>
>  >
>  > In anticipation of keystone setting enforce_scope=True and removing
>  > old default policies (which I assume effectively removes
>  > enforce_new_defaults?), we will set this in kolla-ansible, and try to
>  > deal with any fallout. Hopefully the previous work will make this
>  > minimal.
>  >
>  > How does that line up with other projects' approaches? What have we missed?
>
> Yeah, we want users/deployment projects/horizon etc to use the new policy from
> keystone as first and we will see feedback how they are (good, bad, really bad) from
> usage perspective. Why we choose keystone is, because new policy are there since
> many cycle and ready to use. Other projects needs to work their policy as per new
> SRBAC design/direction (for example nova needs to modify their policy before we ask
> users to use new policy and work is under progress[2]).
>
> I think trying in kolla will be good way to know if we can move to keystone's new policy
> completely in yoga.

We have a scope-enforcing preview patch [1], and it's passing our base
set of tests. I have another that triggers all of the jobs.

[1] https://review.opendev.org/c/openstack/kolla-ansible/+/825406
>
> [1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#z-release-timeline
> [2] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
>
> -gmann
>
>  >
>  > Mark
>  >
>  > [1] https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst
>  > [2] https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#yoga-timeline-7th-mar-2022
>  > [3] https://opendev.org/openstack/kolla-ansible/commit/2e933dceb591c3505f35c2c1de924f3978fb81a7
>  > [4] https://review.opendev.org/c/openstack/kolla-ansible/+/815577
>  > [5] https://etherpad.opendev.org/p/enabling-system-scope-in-kolla-ansible
>  >
>  >