Hide Forgot
Description of problem: I attempt to create a user that would have all permissions in specfic Cloud but not to Cloud provide. Following are some exchanges on this topic: >>> >>> I've created 3 users >>> >>> raadmin - added Administrator >>> >>> sadev - removed all existing global permissions and added Profile amd Images Administrator >>> >>> dev - removed all global permsions >>> >>> I created Cloud >>> named refarch >>> added accounts >>> add dev and sadev as Cloud Users >>> >>> In refarch Cloud I created 3 Cloud Resource Zones - dev, test, prod >>> Each has a catalog (devcat, testcat, prodcat) >>> >>> dev Zone has dev and sadev as Zone users, raadmin as a Zone Owner >>> >>> the default cloud - removed roles for all added users >>> >>> >>> >>> --- >>> when logged in a raadmin - had access that I thought - wish I could limit it to a Cloud >>> >> What rights would you expect a cloud-specific admin to have? It's fairly easy (on the back end -- no UI for this) to add new roles, but we need to make sure the role would have the expected rights/privileges. In addition, we probably need some (minor) code changes on the model side to make sure that some of the existing pool/deployment/etc roles correctly inherit all the way up to the cloud -- i.e. so a 'cloud admin' could access all deployments/instances/pools/images/catalogs/etc. >> >> Certain rights would _not_ come aong with the 'cloud admin' role -- for example, anything associated with providers, provider accounts, profiles, or realms/cloud resource clusters -- as these resources are not scoped to specific clouds. > > I think we are on the same page, I 'd like my raadmin user to be able to thin relates to thier cloud, build/push/launch, modify Zones and catalogues, assign roles and accounts to the elements - but as you say they should not effect Cloud resource provider attributes. > OK great -- could you put in a BZ to clarify/define/fix-what's necessary on the Cloud/Pool Family admin role? Version-Release number of selected component (if applicable): [root@cf-cloudforms5 ~]# /pub/scripts/post_install_configuration_scripts/cf-versions Red Hat Enterprise Linux Server release 6.2 (Santiago) Linux cf-cloudforms5.cloud.lab.eng.bos.redhat.com 2.6.32-220.4.1.el6.x86_64 #1 SMP Thu Jan 19 14:50:54 EST 2012 x86_64 x86_64 x86_64 GNU/Linux postgresql-8.4.9-1.el6_1.1.x86_64 mongodb-1.8.0-6.el6.x86_64 euca2ools-1.3.1-4.el6_0.noarch ruby-1.8.7.352-5.el6_2.x86_64 rubygems-1.8.10-1.el6.noarch deltacloud-core-0.5.0-4.rc1.el6.noarch rubygem-deltacloud-client-0.5.0-1.rc2.el6.noarch package libdeltacloud is not installed hail-0.8-0.2.gf9c5b967.el6_0.x86_64 puppet-2.6.11-1.el6_1.noarch aeolus-configure-2.5.0-11.el6.noarch iwhd-1.2-3.el6.x86_64 imagefactory-1.0.0rc3-1.el6.noarch aeolus-conductor-daemons-0.8.0-20.el6.noarch aeolus-conductor-0.8.0-20.el6.noarch [root@cf-cloudforms5 ~]# How reproducible: yes Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hugh marked this a blocker? so I made it a blocker+
Patches posted here: https://fedorahosted.org/pipermail/aeolus-devel/2012-February/009249.html (7 patches total, all in the thread above)
This is all pushed to master now: 22429ada97e36ff95ddcd5792769050a05ade289 72f4dff042c6df8f6943ee17fecbaf35d92ebf7a 4528dee1c2106a505b6556a435db8185387f7da4 effa647d888d5a147441c3226954371e082bbbc7 afa011974e2753fa668503f93a059350fcb279eb 9bb866f7fb7cc71ce04ebb9ecfb1d3cbdfd61c73
assigning to Pushpesh
1.cloud_user is only able to view its cloud and can not visit any Cloud Resource Zone and cannot do anything with images. (Expected behaviour) 2.cloud_image_admin is able to build and push images,create application blueprints but not able to launch applications or add provider accounts (Expected Behaviour) 3.cloud_admin is able to build and push images,create application blue print and launch applications. Add provider accounts and assign roles to more user.(Expected Behaviour) I feel as per the requirements specified for Cloud Specific roles, these three roles will be sufficient.Marking this bug as verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-0583.html