Admin can't create/update stack with nova flavor

Bug #1529354 reported by huangtianhua on 2015-12-26
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Heat
Fix Released
High
huangtianhua

Bug Description

1. create a stack with nova flavor resource, the user has the role 'admin'
2. the stack create successful
3. modify the conf to enable reauth: reauthentication_auth_method=trusts
4. restart the heat-engine
5. update the stack, then an error raised: You are not authorized to use OS::Nova::Flavor
6. create a new stack with the same template(with nova flavor), an error raised: Policy doesn't allow os_compute_api:os-flavor-manage to be performed, the details: http://paste.openstack.org/show/482712/

Then I checked the conf of my devstack, found out the conf as bellow:
deferred_auth_method=trusts
trusts_delegated_roles='_member_'
reauthentication_auth_method=trusts(before step 3, this is the default value '')

I think this bug introduced by #1306294
https://github.com/openstack/heat/blob/master/heat/engine/service.py#L855-L857
https://github.com/openstack/heat/blob/master/heat/engine/service.py#L735-L737

As above codes, if we enable reauth, we reload the stack after storing it, and will use the new trust-context, but the trust we only delegate '_member_' role, so the policy did not allow to operate the resources which only allow administrator, in this case for nova flavor resource.

Changed in heat:
assignee: nobody → huangtianhua (huangtianhua)
importance: Undecided → High
Changed in heat:
milestone: none → mitaka-2
Oleksii Chuprykov (ochuprykov) wrote :

Hi. I'm not sure that this is a bug. Please see this line https://github.com/openstack/heat/blob/master/heat/common/heat_keystoneclient.py#L219 . So if you put reauthentication_auth_method=trusts in your conf you need to ensure that you set trusts_delegated_roles properly. Also such problem can arise in any case where you use stored_context, not necessary if you set deferred_auth_method=trusts.

The most simple and quick solution may be to insert one more check here https://github.com/openstack/heat/blob/master/heat/common/heat_keystoneclient.py#L219 if we decide that this actually a bug.

Oleksii Chuprykov (ochuprykov) wrote :

...not necessary if you set reauthentication_auth_method=trusts*

huangtianhua (huangtianhua) wrote :

I don't agree with you. As above tests, if I disable reauth, the create and update are successful, only if I enable to reauth in this case, the create and update are failed. I'm thinking the conf 'trusts_delegated_roles' , we used it to create a trust which only for deferred action(such as resource signal), so this conf shouldn't be used for 'current' action(create/update), I suggest to create trust which inherit all roles for 'current' action, and create a trust which inherit subset roles configured by 'trusts_delegated_roles', the logic something like:
********stack.py************
def store():
......
      defer_creds = None

          if cfg.CONF.deferred_auth_method == 'trusts':
                    keystone = self.clients.client('keystone')
                    trust_ctx = keystone.create_trust_context()
                    new_creds = ucreds_object.UserCreds.create(trust_ctx)
                else:
                    new_creds = ucreds_object.UserCreds.create(self.context)
                s['user_creds_id'] = new_creds.id
                self.user_creds_id = new_creds.id

huangtianhua (huangtianhua) wrote :

sorry, press button error.

the logic something like:
********stack.py************
def store():
......
          defer_creds = None
          if cfg.CONF.deferred_auth_method == 'trusts':
              keystone = self.clients.client('keystone')
              trust_ctx = keystone.create_trust_context(for_deferred_action=False) ---here we inherit all roles, the default behaviour
              new_creds = ucreds_object.UserCreds.create(trust_ctx)
              if cfg.CONF.trusts_delegated_roles:
                  defer_context = keystone.create_trust_context(for_deferred_action=True) ---here we inherit subset roles
                  defer_creds = ucreds_object.UserCreds.create(defer_context)
          else:
                  new_creds = ucreds_object.UserCreds.create(self.context)
          defer_creds = defer_creds if defer_creds else new_creds
          s['user_creds_id'] = new_creds.id
          self.user_creds_id = new_creds.id
          s['defer_creds_id'] = defer_creds.id
          self.defer_creds_id = defer_creds.id

Then, when creating stack, we reload the stack, use context which inherit all roles;
When resource signal, we reload the stack, use deferred context which inherit subset of roles.

huangtianhua (huangtianhua) wrote :

If we enable reauth, we can't update the stack with a nova flavor resource, even if 'trusts_delegated_roles = []', due the stored_context has no roles, then the policy check for rule will fail:
 "context_is_admin": "role:admin"
"resource_types:OS::Nova::Flavor": "rule:context_is_admin"

Fix proposed to branch: master
Review: https://review.openstack.org/262156

Changed in heat:
status: New → In Progress

Fix proposed to branch: master
Review: https://review.openstack.org/262361

Fix proposed to branch: master
Review: https://review.openstack.org/263935

Changed in heat:
assignee: huangtianhua (huangtianhua) → Steven Hardy (shardy)
Changed in heat:
assignee: Steven Hardy (shardy) → huangtianhua (huangtianhua)

Reviewed: https://review.openstack.org/263935
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=ce46629661322915082ece2710bf36c46b13a15a
Submitter: Jenkins
Branch: master

commit ce46629661322915082ece2710bf36c46b13a15a
Author: Steven Hardy <email address hidden>
Date: Tue Jan 5 22:41:05 2016 +0000

    Populate context roles when using stored context

    Currently we leave the context roles empty when loading the stored
    context, even though there are roles associated with e.g the trust
    scoped token used via loading the stored context. Loading the auth
    ref and populating the roles from the token ensure any RBAC performed
    on the context roles will work as expected.

    Change-Id: I7d699bcf947940357a6eb6ae2d17027ec8d6bd04
    Closes-Bug: #1529354

Changed in heat:
status: In Progress → Fix Released
Changed in heat:
status: Fix Released → In Progress
Sergey Kraynev (skraynev) wrote :

move to m3 due to confusing status

Changed in heat:
milestone: mitaka-2 → mitaka-3

Change abandoned by huangtianhua (<email address hidden>) on branch: master
Review: https://review.openstack.org/262156

Change abandoned by huangtianhua (<email address hidden>) on branch: master
Review: https://review.openstack.org/262361
Reason: https://review.openstack.org/#/c/269456/

This issue was fixed in the openstack/heat 6.0.0.0b2 development milestone.

Doug Hellmann (doug-hellmann) wrote :

This issue was fixed in the openstack/heat 6.0.0.0b2 development milestone.

Reviewed: https://review.openstack.org/276599
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=65fe32d3ac9ce8e92880e443834f9fc8f7192d46
Submitter: Jenkins
Branch: stable/liberty

commit 65fe32d3ac9ce8e92880e443834f9fc8f7192d46
Author: Steven Hardy <email address hidden>
Date: Tue Jan 5 22:41:05 2016 +0000

    Populate context roles when using stored context

    Currently we leave the context roles empty when loading the stored
    context, even though there are roles associated with e.g the trust
    scoped token used via loading the stored context. Loading the auth
    ref and populating the roles from the token ensure any RBAC performed
    on the context roles will work as expected.

    Change-Id: I7d699bcf947940357a6eb6ae2d17027ec8d6bd04
    Closes-Bug: #1529354
    (cherry picked from commit ce46629661322915082ece2710bf36c46b13a15a)

tags: added: in-stable-liberty
Sergey Kraynev (skraynev) wrote :

Fix was merged in master. So Update status manually

Changed in heat:
status: In Progress → Fix Released

This issue was fixed in the openstack/heat 5.0.2 release.

Change abandoned by Rico Lin (<email address hidden>) on branch: master
Review: https://review.openstack.org/269456
Reason: Hi, this patch stays untouched for few months, would like to abandon for now. Feel free to restore it if you still working on this. Thank you!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers