Page History

...

Current implementation of the list APIs is tied tightly with the default roles  (root admin,domainadmin, regular user), and we have hard-coded logic baked in to handle these three out-of-box roles differently.The List APIs do not interpret the listing parameters in a standard way across board. Depending on which role is invoking the call, the logic assumes some default behavior in the given context and provides results by ignoring the passed listing parameter. Most contradictory parameters are these four: listall, isrecursive, domainid, account.  Here is a summary of current API behavior in handling these four APIs;

There are several issues with current behavior:

...

With this hard-coded baked logic specific to each account type, the implementation will be very hard to extend to handle true IAM usecases with customized roles introduced, since we need to define what the meaning of these parameters for those customized roles. With real IAM, the listing should follow a standard pattern and work with the list API parameters irrespective of who is the caller - the IAM policies attached to the caller should drive the results.

 B]For

Create APIs

...

...

• The owner of the entities being created is implicitly derived from other entities used in the creation

...

• . This will break granting, even if user A grants a resource to user B, the entity created by user B is still owned by user A.

Example: AssociateIpAddress from a Network, always sets the Network owner as the owner of the IpAddress acquired newly. This implicit derivation will break IAM granting across accounts. Since if Account A grants her network to Account B, the IpAddress Account B acquires will still be owned by account A. So the grant does not really work.

 

...

• Incorrect impersonation implementation. For some create APIs, they accept (domainId, account) parameters to allow admin to perform this create operation on behalf of the passed account. But internally service layer access checker is still based on the caller (admin itself instead of the impersonated person), this is incorrect. To make this work in current API, CloudStack code has to give absolute power to root admin, which is violating IAM rules.

Impersonation Semantics

Few CS APIs accept account-domain parameters and do impersonation based on these parameters. But as a way to indicate impersonation, but this is not followed across all APIs. So to support impersonation via IAM, we need to change APIs to deprecate these (account, domainId) impersonation and come up with a new impersonate API to have a standard impersonation mechanism. 

 In order to make them compatible with IAM, we need changes to the API semantics which will break backwards compatibility for existing deployments. So we need a API version change to accommodate IAM support.