[rhos-list] Control Access to instance termination

[Eoghan Glynn]

> Hi,
> 
> Where I can get a complete list of policy.json options?

Good question, I can't find a complete list in the upstream docco.

This section

  "If we wished to restrict all Compute service requests to require
  this role, the resulting file would look like:" ...

http://docs.openstack.org/trunk/openstack-compute/install/yum/content/keystone-concepts.html

implies a full list, but the file quoted does not include every
fine-grained policy (perhaps relying on the default policy to
fill in the gaps).

But looking directly at the source, here's a list of policies
associated with the compute API:

 compute:create
 compute:create:forced_host
 compute:create:attach_network
 compute:create:attach_volume
 compute:get
 compute:get_all
 compute:get_all_tenants
 compute:detach_volume
 compute:get_instance_faults
 compute:update
 compute:soft_delete
 compute:delete
 compute:restore
 compute:force_delete
 compute:start
 compute:backup
 compute:snapshot
 compute:rebuild
 compute:revert_resize
 compute:confirm_resize
 compute:resize
 compute:add_fixed_ip
 compute:remove_fixed_ip
 compute:pause
 compute:unpause
 compute:get_diagnostics
 compute:suspend
 compute:resume
 compute:rescue
 compute:unrescue
 compute:set_admin_password
 compute:inject_file
 compute:get_vnc_console
 compute:get_spice_console
 compute:get_console_output
 compute:lock
 compute:unlock
 compute:get_lock
 compute:reset_network
 compute:inject_network_info
 compute:attach_interface
 compute:detach_interface
 compute:get_instance_metadata
 compute:delete_instance_metadata
 compute:update_instance_metadata
 compute:security_groups:add_to_instance
 compute:security_groups:remove_from_instance
 
> I also noticed the policy.json file but couldn't find a documentation
> for it.
> 
> I also wanted to restrict the viewership of the servers to the
> owner_user, project_admin and admin only.
> So he can access/change the other users' instances.

"He" in this context being the admin role?

Presumably also project_admin is a custom role you've created yourself?

IIUC the rule you'd need would go something like:

  role:admin or (role:project_admin and project_id:%(project_id)s) or user_id:%(user_id)s

or using the older syntax:

  [["role:admin"], ["role:project_admin", "project_id:%(project_id)s"]], ["user_id:%(user_id)s"]]

Cheers,
Eoghan

> 
> Regards,
> Vaibhav
> 
> 
> 
> ---------- Original message ----------
> From:"Eoghan Glynn"< eglynn at redhat.com >
> Date: 25 Mar 13 18:21:48
> Subject: Re: [rhos-list] Control Access to instance termination
> To: Kumar Vaibhav <vaibhav.k.agarwal at in.com>
> Cc: rhos-list <rhos-list at redhat.com>
> 
> 
> 
> > Hi,
> > 
> > I want to restrict the user to see other user's instances.
> > 
> > Default behaviour is that a user can see all the servers in his
> > tenant-id.
> > 
> > He can suspend, delete, pause etc to the instances created by the
> > other users.
> > 
> > Can this be restrict ed? I want the full previlige to the
> > owner(user
> > who created the instance) of the instance. And no privilige to the
> > other users (except admin) on other users' instances.
> > 
> > I don't want to create a tenant for each user to solve this
> > problem.
> > 
> > Regards,
> > Vaibhav
> 
> 
> This is a requirement that would ideally be handled via the
> rules-based
> access control (RBAC) logic.
> 
> Currently in nova, a rule such as:
> 
> "admin_or_owner": "is_admin:True or project_id:%(project_id)s"
> 
> can be used to specify that an action is restricted to the admin
> role or the tenant owning the resource.
> 
> What you would need I believe is a rule like:
> 
> "admin_or_user": "is_admin:True or user_id:%(user_id)s",
> 
> then restrict the instance delete etc. actions via:
> 
> "compute:delete": "rule:admin_or_user",
> # ... etc.
> 
> All changes applied to /etc/nova/policy.json followed by:
> 
> # serv ice openstack-nova-api restart
> 
> I've tested briefly against master upstream, but I'd be interested
> hearing your experience with the RHOS version you've got deployed.
> 
> Cheers,
> Eoghan
> 
> 
> 
> Get Yourself a cool, short @in.com Email ID now!