Open Stack

 ---- On Thu, 20 Jan 2022 07:37:51 -0600 Sean Mooney <smooney at redhat.com> wrote ----
 > On Thu, 2022-01-20 at 13:23 +0000, Sean Mooney wrote:
 > > On Thu, 2022-01-20 at 09:05 +0900, Takashi Kajinami 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-reader
 > > > to 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 yet
 > > > clear 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
 > > > appropriate
 > > > but what is the main intention is to allow project/domain scope ?
 > > a token is really a resouce belownign to a user and that user can be a member of a project or doamin.
 > > do we need to enfoce any scope on this endpoint?
 > > 
 > > the token that the midelware is vlaidating shoudl be suffenct to do the validation since that user
 > > shoudl be able to retirve the list of roles and project/domain membership its is part of so i guess
 > > im confusted why we woudl not just pass the token to be ckeck as the token the middelware uses and not enforece
 > > any scope or role reqiruement on the token validation endpoint
 > > 
 > > perhaps im missunderstanding and the authtoken middleware is not the middleware that validate the toke is valid and populates
 > > the project_id and domain_id /roles in the oslo context object?
 > 
 > by the way im asserting that a GET or HEAD query to 
 > 
 > /v3/auth/tokens should not require any scope or role to complete
 > 
 > https://docs.openstack.org/api-ref/identity/v3/?expanded=check-token-detail,validate-and-show-information-for-token-detail#check-token
 > 
 > if the token that is being vlaidated is valid then the request can use the permission on that token to authrise the return of the info
 > if the token is not valid hten it woudl return a 403
 > 
 > openstack uses bearer tokens so the fact that you posess it entirles you to use teh permission allowed by that token.
 > 
 > even a *reader token with no other roles shoudl be able to use the current token to validate itself.
 > so really i dont think this api shoudl require a second token to vouch for it.
 > 
 > i can see some pushing back saying this would weaken the current security model which is valid
 > in which case i woudl proably go with allowing a system-reader token with service roles or something similar.
 > since tokens are nto really proejct or domaing owned but user owned.

As you mentioned, token valdiation is allowed to system, domain, and project scope token so I think
main idea here to have and check scope is to block the unscoped token which is good.

IMO, Not forcing the scope seems more risky. 

-gmann

 > 
 > > > 
 > > > By the way, in Puppet OpenStack, we have been using the service"s" project
 > > > instead of
 > > > the 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
 > > > >  > >>
 > > > >  >
 > > > >  >
 > > > > 
 > > > > 
 > > 
 > 
 > 
 >