Bug 807444
Summary: | provider account access to environments/clouds is not enforced during push | ||
---|---|---|---|
Product: | [Retired] CloudForms Cloud Engine | Reporter: | Dave Johnson <dajohnso> |
Component: | aeolus-conductor | Assignee: | Scott Seago <sseago> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | wes hayutin <whayutin> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1.0.0 | CC: | akarol, athomas, cpelland, deltacloud-maint, morazi, psharma, redakkan, ssachdev, sseago |
Target Milestone: | 1.0.2 | Keywords: | Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-12-13 19:48:32 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Dave Johnson
2012-03-27 19:43:14 UTC
This can also be seen on the deployables page Recreate: 1. create ec2 provider account called ec2_A 2. create ec2 provider account called ec2_B 3. create environmentA 4. give environ Recreate: 1. create ec2 provider account called ec2_A 2. create ec2 provider account called ec2_B 3. create environmentA 4. give environmentA/CloudA access to provider account ec2_A 5.build a template in cloudA 6.push a template in cloudA Notice that during the push process that all ec2 provider accounts are available to the component outline/image This definitely looks like a regression, as it was working as expected with the initial roll-out of environment-scoping of images. It's slightly confusing to refer to "access" since that implies permissions -- the issue here has to do with the linking of clouds and provider accounts and, apparently, build/push isn't properly restricting building and pushing to only those accounts that are linked with the environment. Recreate: 1. Create a new cloud with two provider accounts ie vsphere,rhevm 2. build image to both the account using 'build all' 3. now remove the rhevm account from cloud 4. pushed image to vsphere 5. view the image detail page Observed that, the rhevm provider detail without account was present, after some time the account details also came up with Image UUID and image URI on: rpm -qa | grep aeolus aeolus-conductor-0.8.13-1.el6_2.noarch aeolus-configure-2.5.3-1.el6.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch rubygem-aeolus-cli-0.3.1-1.el6.noarch aeolus-all-0.8.13-1.el6_2.noarch aeolus-conductor-doc-0.8.13-1.el6_2.noarch aeolus-conductor-daemons-0.8.13-1.el6_2.noarch We should also check the cli and open a corresponding bug. If the same thing happens via cli please clone this for the cli. Ok here's another one I can't replicate now -- it looks like the bug has been fixed more recently 1. create ec2 provider account called ec2_A 2. create ec2 provider account called ec2_B 3. create environmentA 4. give environmentA/CloudA access to provider account ec2_A 5.build a template in cloudA 6.push a template in cloudA Notice that during the push process only ec2_A accounts is available to the component outline/image.Bo other accounts are added.(there were 2 more) Verified on :- [root@dhcp201-113 ~]# rpm -qa|grep aeolus rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-all-0.13.8-1.el6cf.noarch aeolus-conductor-0.13.8-1.el6cf.noarch rubygem-aeolus-cli-0.7.1-1.el6cf.noarch aeolus-configure-2.8.6-1.el6cf.noarch aeolus-conductor-daemons-0.13.8-1.el6cf.noarch aeolus-conductor-doc-0.13.8-1.el6cf.noarch [root@dhcp201-113 ~]# |