[rbac][keystone][kolla][osa][tripleo][charms] RBAC in Yoga for deployment projects

Ghanshyam Mann gmann at ghanshyammann.com
Fri Jan 21 23:55:22 UTC 2022


 ---- On Thu, 20 Jan 2022 13:43:03 -0600 Mark Goddard <mark at stackhpc.com> wrote ----
 > On Thu, 20 Jan 2022 at 18:53, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 > >
 > >  ---- On Wed, 19 Jan 2022 18:05:11 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 > >  > Thank you, Ghanshyam, for your inputs.These are helpful to understand the latest plan.
 > >  > So I think our question comes back to the original one.Currently keystone allows any of 1. system-service 2. domain-service
 > >  >  3. project-service 4. system-admin 5. system-member 6. system-readerto validate token but which one is the appropriate one to be used by authtoken middleware ?
 > >  > Considering the purpose of the service role, the service role is appropriate but it's not yetclear which scope should be used (as is pointed out by Mark from the beginning).
 > >  > AFAIK token is not a resource belonging to projects so system scope looks appropriatebut what is the main intention is to allow project/domain scope ?
 > >
 > > IMO, general service role enforcement will look like:
 > >
 > > - They will enforce the same scope as APIs. For example, neutrons call nova APIs X (server external event APIs). Nova
 > > APIs default policy will add service role like below:
 > >
 > >   policy.DocumentedRuleDefault(
 > >        name='os_compute_api:os-server-external-events:create',
 > >        check_str='role:admin or role:service',
 > >        scope_types=['project']
 > >    )
 > >
 > > and neutron will call the service role token with project scoped.
 > 
 > Which project would be in scope here? I don't think it makes sense to
 > use the project of the resource that the event is for, since these
 > calls are generally asynchronous, so we won't have the user's context.
 > Currently for these service API calls AFAIK we're using a service user
 > (e.g. nova) which has the admin role in the service project.

Those are good points and honestly saying I do not have answer to those yet.
We will see while implementing those service role and per APIs/Service case
by case. 

-gmann

 > 
 > >
 > > Same applies to token validation APIs also, as you know, it is allowed to
 > > any scope (system, domain, project) so allowed service role in any scope
 > > can be used. Answer to your question on which one is appropriate is that
 > > you can use any of mentioned one as they are allowed (that is how users
 > > will be accessing it).
 > >
 > > I hope it answer your query but again service roles are not implemented yet
 > > so policy default may change especially from project side policy, hoping keystone
 > > policy are all good and will not change but let's wait until this spec
 > > - https://review.opendev.org/c/openstack/keystone-specs/+/818616
 > >
 > > -gmann
 > >
 > >  >
 > >  > By the way, in Puppet OpenStack, we have been using the service"s" project instead ofthe service project for some reason(which I'm not aware of).So it's helpful for us if we avoid implementing strict limitations to use the service project.
 > >  >
 > >  >
 > >  > On Thu, Jan 20, 2022 at 1:29 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 > >  >  ---- On Wed, 19 Jan 2022 08:01:00 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 > >  >  >
 > >  >  > On Wed, Jan 19, 2022 at 9:22 PM Mark Goddard <mark at stackhpc.com> wrote:
 > >  >  > On Wed, 19 Jan 2022 at 11:15, Takashi Kajinami <tkajinam at redhat.com> wrote:
 > >  >  > >
 > >  >  > > Hi,
 > >  >  > >
 > >  >  > >
 > >  >  > > (The topic doesn't include puppet but ...)
 > >  >  > > I recently spent some time implementing initial support for SRBAC
 > >  >  > > in Puppet OpenStack. You can find details in the etherpad[1] I created
 > >  >  > > as my working note. It includes some items commonly required by all toolings
 > >  >  > > in addition to ones specific to puppet.
 > >  >  > >  [1] https://etherpad.opendev.org/p/puppet-secure-rbac
 > >  >  >
 > >  >  > Thanks for responding, Takashi - that's useful.
 > >  >  >
 > >  >  > >
 > >  >  > > I expect some of them (especially the configuration parameters) would be used
 > >  >  > > by TripleO later.
 > >  >  > >
 > >  >  > > > 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.
 > >  >  > >
 > >  >  > > I'd add one more question which is;
 > >  >  > >  Which roles should be assigned for the service users ?
 > >  >  > >
 > >  >  > > In the project which already implemented SRBAC, system-admin + system-reader
 > >  >  > > allows any API calls and works like the previous project-admin.
 > >  >  >
 > >  >  > IIUC the direction of travel has changed, and now the intention is
 > >  >  > that system-admin won't have access to project-scoped APIs.
 > >  >
 > >  > Yes, as mark mentioned. And that is the key change from prevous direction.
 > >  > We are isolating the system and project level APIs. system token will be able
 > >  > to perform only system level operation and not allowed to do project level
 > >  > operation. For example: system user will not be allowed to create the server
 > >  > in nova. To have a quick view on those (we have not finished yet in nova), you
 > >  > can check how it will look like in the below series:
 > >  >
 > >  > - https://review.opendev.org/q/topic:%22bp%252Fpolicy-defaults-refresh-2%22+(status:open%20OR%20status:merged)
 > >  >
 > >  > You can see the test cases for all four possible configuration combination and what all
 > >  > roles are allowed in which configuration (case 4th is end goal we want to be for RBAC):
 > >  >
 > >  > 1. enforce_scope=False + legacy rule (current default policies)
 > >  > 2. enforce_scope=False + No legacy rule (enable scope but remove old policy default)
 > >  > 3. enforce_scope=True + legacy rule  (enable scope with old policy default)
 > >  > 4. enforce_scope=True + no legacy rule (end goal of new RBAC)
 > >  >
 > >  >  >
 > >  >  > >
 > >  >  > > For token validations system-reader(or service role) would be enough but there are
 > >  >  > > some system-admin-only APIs (os-server-external-events API in nova called by neutron,
 > >  >  > > Create allocation in placement called by nova or neutron) used for communications
 > >  >  > > between services.
 > >  >  >
 > >  >  > The token validation API has the following default policy:
 > >  >  >
 > >  >  > identity:validate_token: (role:reader and system_scope:all) or
 > >  >  > rule:service_role or rule:token_subject
 > >  >  >
 > >  >  > So system-reader, system-admin or service (any scope) should work. The
 > >  >  > spec suggests that the service role is intended for use by service to
 > >  >  > service APIs, in this case the credentials provided in the
 > >  >  > keystone_authtoken config. I would guess that system scope makes most
 > >  >  > sense here with the service role, although the rule suggests it would
 > >  >  > work with project scope and the service role.
 > >  >  >
 > >  >  > I noticed I ignored implied roles... Thanks for clarifying that.
 > >  >  > I understand and I agree with this. Considering the intention of SRBAC this would fixbetter with system-scoped, as you earlier mentioned but I'll defer to the others. >
 > >  >
 > >  > Another thigns to note here is, in Yoga cycle we are doing only system-admin. system-reader,
 > >  > system-member will be done in phase3 which is for future releases (BB).
 > >  >
 > >  >  > > If we agree system-admin + system-reader is the right set then I'll update the default role
 > >  >  > > assignment accordingly. This is important for Puppet OpenStack because there are implementations
 > >  >  > > in puppet (which is usually called as providers) to manage some resources like Flavors,
 > >  >  > > and these rely on credentials of service users after trying to look up user credentials.
 > >  >  >
 > >  >  > I think one of the outcomes of this work is that authentication will
 > >  >  > necessarily become a bit more fine-grained. It might not make sense to
 > >  >  > have the same role assignments for all users. To your example, I would
 > >  >  > say that registering flavors should be done by a different user with
 > >  >  > different permissions than a service user. In kolla-ansible we don't
 > >  >  > really register flavors other than for octavia - this is up to
 > >  >  > operators.
 > >  >  > My main concern was that some service users would require system-admin butI should have read this part more carefully. https://opendev.org/openstack/governance/src/branch/master/goals/selected/consistent-and-secure-rbac.rst#phase-2
 > >  >  > So Assigning the service role (for the proper scope which is asked in the original thread)is the right way to go. For the provider stuff I'll look into any available option to replace usage of serviceuser credential but that's specific to Puppet which we can ignore here in this discussion.
 > >  >
 > >  > right, once we have service role implemented then we will have clear way on how services will be
 > >  > communicating to other services APIs.
 > >  >
 > >  > -gmann
 > >  >
 > >  >  >
 > >  >  > >
 > >  >  > > Takashi
 > >  >  > >
 > >  >  > > On Wed, Jan 19, 2022 at 7:40 PM 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.
 > >  >  > >>
 > >  >  > >> 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?
 > >  >  > >>
 > >  >  > >> 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
 > >  >  > >>
 > >  >  >
 > >  >  >
 > >  >
 > >  >
 > 
 > 	



More information about the openstack-discuss mailing list