Bug 1303099 - service retirement requests are always ran by the admin user
service retirement requests are always ran by the admin user
Status: CLOSED NOTABUG
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Automate (Show other bugs)
5.5.0
All All
medium Severity high
: GA
: 5.5.3
Assigned To: Tina Fitzgerald
Dave Johnson
: Reopened, ZStream
Depends On: 1297382
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-29 09:36 EST by John Prause
Modified: 2016-02-12 08:59 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1297382
Environment:
Last Closed: 2016-02-12 08:59:52 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2158341 None None None 2016-02-11 05:47 EST

  None (edit)
Comment 1 Tina Fitzgerald 2016-02-02 14:52:14 EST
I ran some tests on version 5.5.0.13.20151201120956_653c0d4 and found that it appeared to work properly.  

My scenario:
Top tenant user: admin 
          group: EvmGroup-super_administrator 
         tenant: top_tenant
A new automate domain named "top_tenant" created by user "admin" 
Note - I copied the start retirement method from the "ManageIQ" domain so I could add logging about what domain it was running from.

Sub tenant user: test 
          group: park_rangers 
         tenant: yosemite
A new automate domain named "yosemite" created by user "test" 
Note - I copied the start retirement method from the "ManageIQ" domain so I could add logging about what domain it was running from.

As user "test":
Created a new generic service item called "tina_test".
Provisioned service had the correct user, group and tenant ids for user "test".
Retired service. Retirement methods executed from my "yosemite" domain which is correct. I would have suspected it would go through the "top_tenant" domain if was retiring as user "admin"
 
[----] I, [2016-02-02T14:06:29.950477 #3087:2fe3024]  INFO -- : <AEMethod start_retirement> TINA - executing retirement in yosemite domain:

Does this scenario capture your use case? 
If not, what should I change?

Thanks,
Tina
Comment 3 Tina Fitzgerald 2016-02-03 18:48:46 EST
The behavior differs in my environment using build: 5.5.0.13.20151201120956_653c0d4

Can you provide the following:
1. The build number using configure -> about.
2. Where did you get the tenant object logged in the "init" method referenced above? Can you provide a copy of that method?
Comment 5 mkanoor 2016-02-04 18:07:28 EST
The reason that the user is switched to admin during retirement is because the logged in user's group doesn't contain the service owner's group.

When the service provision starts the ids are
:user_id=>1000000000004, :miq_group_id=>1000000000056, :tenant_id=>1000000000002

Then there is a customer method which seems to be changing the tenant on the service.
The method is /Gcloud/Cloud/Orchestration/Provisioning/StateMachines/Methods/setServiceIdentity

This method has a log line which states that changing the tenant
<AEMethod setserviceidentity> Set service tenant id to 1000000000018

The Service gets provisioned and the identity of the service is changed to
evm_owner_id: 1000000000004, miq_group_id: 1000000000095, tenant_id: 1000000000018


The provisioning started with tenant_id of 1000000000002 and was changed to 
1000000000018
And also the group is changed.

Changing of the group this way causes the retirement to run as admin.

Can we get some more details from the customer if they are trying to change the service tenant, group during provisioning.

The user should be part of these groups if the user shouldn't get swapped with 'admin'
Comment 6 Felix Dewaleyne 2016-02-11 05:47:35 EST
(In reply to mkanoor from comment #5)
> The reason that the user is switched to admin during retirement is because
> the logged in user's group doesn't contain the service owner's group.
> 
> When the service provision starts the ids are
> :user_id=>1000000000004, :miq_group_id=>1000000000056,
> :tenant_id=>1000000000002
> 
> Then there is a customer method which seems to be changing the tenant on the
> service.
> The method is
> /Gcloud/Cloud/Orchestration/Provisioning/StateMachines/Methods/
> setServiceIdentity
> 
> This method has a log line which states that changing the tenant
> <AEMethod setserviceidentity> Set service tenant id to 1000000000018
> 
> The Service gets provisioned and the identity of the service is changed to
> evm_owner_id: 1000000000004, miq_group_id: 1000000000095, tenant_id:
> 1000000000018
> 
> 
> The provisioning started with tenant_id of 1000000000002 and was changed to 
> 1000000000018
> And also the group is changed.
> 
> Changing of the group this way causes the retirement to run as admin.
> 
> Can we get some more details from the customer if they are trying to change
> the service tenant, group during provisioning.
> 
> The user should be part of these groups if the user shouldn't get swapped
> with 'admin'

thanks, that effectively was the problem and thanks to your update the case has been resolved! 

I'm creating https://access.redhat.com/solutions/2158341 to cover this problem, maybe you can help me expand it further?
Comment 7 Tina Fitzgerald 2016-02-11 15:12:02 EST
Hi Felix,

We added some content to your solution article. 

This is an important issue and we'd like to better understand how the customer modified the values and how they resolved the issue. Can you give us more detail about the customer environment? Could we have a copy of the setserviceidentity automate method?   

Thanks,
Tina

Note You need to log in before you can comment on or make changes to this bug.